EC-ի մեր ընկերություններից շատերի աշխատակազմում կան ասպիրանտներ։ Բայց իմ դիտարկմամբ՝ այդ ասպիրանտները հազվադեպ են հետազոտություն անում այն ընկերությունների համար, որտեղ աշխատում են։ Փոխարենը նրանց թեմաները սահմանում են համալսարանների պրոֆեսորները։

Բայց սա ափսոս է և բաց թողնված հնարավորություն։

Ճարտարագիտության ասպիրանտներն ապագայի տեխնոլոգիաների հետազոտություն են անում։ Ապագայի տեխնոլոգիաների հետազոտությունը պետք է դառնա այն ընկերությունների նոր արտադրանքի առանցքը, որտեղ նրանք աշխատում են։

Ընկերությունները պետք է համագործակցեն համալսարանների պրոֆեսորների հետ՝ ասպիրանտների հետազոտական նախագծերը սահմանելիս։

Հակառակ դեպքում դրանք ընկերությունների համար բաց թողնված հնարավորություններ կլինեն։

Մենք շարունակում ենք կատարելագործել BOM-ի ներկայացման գործընթացը ավտոմատացնող աշխատանքային հոսքը։ Ընթացիկ ամբողջական աշխատանքային հոսքը տե՛ս ստորև նկարում (տե՛ս Նկար 1)։ Արտաքնապես այն շատ է փոխվել, բայց իրականում տրամաբանությունը մնում է նույնը։

Այս քայլում մենք լուծեցինք ժամանակի արդյունավետ կառավարման և տվյալների ստուգման հետ կապված մի քանի խնդիր, աշխատանքային հոսքին ստիպեցինք կատարել ավելի բարդ առաջադրանքներ և աշխատեցինք աշխատանքային հոսքի ընթեռնելիության վրա։

Այսպիսով, աշխատանքային հոսքի այս տարբերակը շատ ավելի պարզ է թվում, քան նախորդ հոդվածինը։ Այստեղ օգտագործել ենք ենթահոսքեր (Sub-workflows)։ Դրանք առանձին աշխատանքային հոսքեր են ավելի մեծի ներսում։ Նկար 1-ում ենթահոսքերը Նկար 2-ում ցույց տրված պատկերակներով հանգույցներն են։

Այժմ յուրաքանչյուր ենթահոսք (պատկերակը՝ ինչպես Նկար 2-ում) նախորդ տարբերակի աշխատանքային հոսքի մաս է։ Սրան կանդրադառնանք ավելի ուշ։

Խնդիր 1. նախագծի BOM-ը կարող է պարունակել մինչև 15 ենթահամակարգ (ենթա-BOM), որոնք բոլորը առանձին ֆայլերում են (դրանք նույն Project ID-ի ներքո են), ուստի դրանք բոլորը պետք է մշակվեն աշխատանքային հոսքով։ Սա մեկ այլ խնդիր է առաջացնում՝

Խնդիր 2. Project ID-ն աշխատանքային հոսքի մշակած տեղեկատվության հիմքն է, ուստի պետք է համոզվենք, որ ներկայացվում է ճիշտ Project ID։

Նախ՝ ենթահամակարգերի ընդհանուր կողմն այն է, որ դրանք վերաբերում են նույն նախագծին (Project ID-ն նույնն է)։ Ուստի Project ID-ն, ամենայն հավանականությամբ, հիմք կընդունվի այս խնդիրը լուծելու համար։ Այսպիսով, սկսեցինք նույն Google Sheets աղյուսակում Project ID-ների տվյալների բազա ստեղծելով (տե՛ս Նկար 3(a), (b) և (c)։

Ենթահամակարգերի առավելագույն թիվը 15 է, ուստի այս տվյալների բազան հասնում է մինչև ենթահամակարգ 15։

Ինչպես տեսնում եք Նկար3(c)-ում, ոչ բոլոր նախագծերն ունեն 14 կամ նույնիսկ 15 ենթահամակարգ, այդ պատճառով որոշ դաշտեր դատարկ են։

Տվյալների բազան մասամբ լրացվում է BOM-ը ներկայացնելուց առաջ, Նկար 3(a)-ն ցույց է տալիս այդ բոլոր բջիջները։

Այժմ այս տվյալների բազայի հիման վրա կարող ենք ստեղծել BOM-ի ներկայացման ձևը։

Project ID-ների տվյալների բազան թույլ է տալիս ստեղծել BOM-ի ներկայացման պատշաճ ձև։ Գոյություն չունեցող Project ID-ի ներկայացումից խուսափելու համար ավելացրել ենք Project ID դաշտ (տե՛ս Նկար 4), որը տալիս է ակտիվ ID-ների բացվող ցանկ՝ յուրաքանչյուրի համար նախագծի անվանումով, որպեսզի հեշտ լինի գտնել անհրաժեշտը։ Այս քայլը կատարում է հետևյալ գործառույթները՝

a. Անհնար է դարձնում իրականում գոյություն չունեցող Project ID-ի ներկայացումը. b. Ցուցադրում է միայն «Active» ID-ները, ինչը նշանակում է, որ կարելի է ընտրել միայն ընթացիկ նախագծերի ID-ները (այստեղ պարզության համար ենթադրում ենք, որ հնարավոր է միայն 2 կարգավիճակ՝ «Active» և «Finished»). c. Կրճատում է աշխատակցի՝ BOM-ի ներկայացման վրա ծախսած ժամանակը՝ նվազեցնելով սթրեսը.

Նախագծի ղեկավարը լրացնում է պահանջվող դաշտերը և անցնում էջ 2։

Էջ 2-ը (տե՛ս Նկար 5) պարունակում է ավտոմատ լրացված տվյալներ 2 աշխատակցի և Project ID-ի մասին՝ թույլ տալով նախագծի ղեկավարին ստուգել ներկայացված տվյալները, և տրամադրում է դաշտեր ենթահամակարգերի համար։ Այժմ կա լրացուցիչ դաշտ, որը հարցնում է «How many Sub Systems are there?» («Քանի՞ ենթահամակարգ կա»)՝ տալով 1-ից 15 բացվող ցանկ։ Ինչպես տեսնում եք Նկար 5(a)-ում, մենք ընտրել ենք 1, ուստի պետք է տրամադրենք տվյալներ 1 ենթահամակարգի մասին (այսինքն՝ յուրաքանչյուր ենթահամակարգ ունի 4 դաշտ)։ Այնուհետև այս տվյալներն ուղարկվում են Project ID-ների տվյալների բազա (տե՛ս Նկարներ 3(b) և (c))։

Սակայն այժմ ներկայացվող տվյալների ձևաչափը փոխվել է։ Ուստի ներկայացումների տվյալների բազան պետք է փոխվի (տե՛ս Նկար 6(a), (b), (c), (d))։

Ավելացրել ենք «Status» սյունակ (տե՛ս Նկար 6(a)), «Personal/Engineer Manager’s Full Name/Email» (նպատակը կքննարկվի ավելի ուշ) (տե՛ս Նկար 6(a), (b)), ենթահամակարգերի թիվը, ենթահամակարգերի հղումները և յուրաքանչյուր հղման համար ձևը ներկայացնելիս ավտոմատ ստեղծվող եզակի ID, ինչպես նաև «Reminder Sent at» սյունակ, որը նույնպես կբացատրվի ստորև (տե՛ս Նկարներ 6(c), (d))։

Այնուհետև, թեև կարելի է ընտրել միայն «Active» Project ID-ներ, դեռ կա ռիսկ, որ ձևը ներկայացնելիս ընտրված Project ID-ն կամ BOM-ում գրվածը սխալ է։ Սխալ Project ID ներկայացնելու վտանգը նվազագույնի հասցնելու համար ստեղծվեց Check the PID with the BOM ենթահոսքը (տե՛ս Նկար 7)։

Այս ենթահոսքը ծնող աշխատանքային հոսքում կոչվում է «Check the PID with the BOM» (տե՛ս Նկար 1)։ Այս ենթահոսքը կատարվում է «Loop over Items1» ալգորիթմից առաջ (տե՛ս Նկար 1), այն ունի իր սեփական «Loop over Items» ալգորիթմը (տե՛ս Նկար 7)։ Այս մասը կատարվում է աշխատանքային հոսքի մնացած մասից առաջ՝ առանձին, քանի որ այն չպետք է թույլ տա այլ հանգույցների կատարումը, եթե ենթահամակարգ(եր)ը չանցնեն այս ստուգումը։

Համառոտ՝ աշխատանքային հոսքի այս մասը համեմատում է ներկայացման ձևով ներկայացված Project ID-ն և BOM-ում (յուրաքանչյուր ենթահամակարգի) գրված Project ID-ն՝ այդպիսով ապահովելով, որ ներկայացվել է ճիշտ ID։ Եթե ոչ, այս ներկայացման տողը ներկայացումների տվյալների բազայում պետք է ջնջվի, քանի որ մուտքային տվյալներն անվավեր են։

Տրամաբանությունն ըստ հանգույցների՝

1. «When Executed by Another Workflow». ծնող աշխատանքային հոսքը գործարկում է ենթահոսքը և ուղարկում տվյալներ։

2. «Leave only Sub Systems». վերցնում է միայն ենթահամակարգերը՝ տվյալների հետագա մշակման համար։

3. «Loop Over Items». ստուգում է յուրաքանչյուր ենթահամակարգ առանձին։

4. «Extract File ID». դուրս է բերում ֆայլի աղյուսակի ID-ն։

5. «Download file». ներբեռնում է ֆայլը՝ ըստ աղյուսակի ID-ի։

6. «Heading Data». այս հանգույցը պարզապես BOM ֆայլից դուրս է բերում տվյալները՝ Project ID-ով հանդերձ։

7. «Compare Project IDs». ստուգում է՝ արդյոք ներկայացված Project ID-ն և որոշակի ենթահամակարգի Project ID-ն համընկնում են։ a. True ճյուղ՝ «Set TRUE». հանգույցը համընկնելու դեպքում աղյուսակի ID-ին տալիս է TRUE արժեք։ b. False ճյուղ՝ «Set FALSE». հանգույցը տալիս է FALSE արժեք, եթե աղյուսակը չի համընկնում։

8. «Merge». ստանում է արժեքը՝ TRUE է, թե FALSE։

9. «Loop Over Items» (done ճյուղ). հավաքում է բոլոր աղյուսակների ID-ների բոլոր արժեքները։

10. «Keep only Mismatches». թողնում է միայն այն աղյուսակների ID-ները, որոնք ստացել են FALSE արժեք։

11. «Get row(s) in sheet».

12. «Get row(s) in sheet1». հանգույցը սկսում է անվավեր տողի ջնջման տրամաբանությունը։ Այս հանգույցը տվյալների բազայից դուրս է բերում բոլոր ներկայացումները՝ հետագա ընթացակարգերի համար։

13. «Last Submission per ProjectID1». յուրաքանչյուր Project ID-ի համար պետք է թողնենք միայն վերջին ներկայացումը՝ անհրաժեշտը ջնջելու համար, քանի որ հակառակ դեպքում կարող ենք ջնջել նույն Project ID-ով ներկայացում, որը համընկնում է BOM-ում նշվածի հետ։

14. «Leave only submitted PID». այս հանգույցով թողնում ենք միայն անվավեր Project ID մուտքագրմամբ ընթացիկ ներկայացումը։

15. «Delete incorrect PID row». ներկայացումների տվյալների բազայից ջնջում է ներկայացման տողը։

16. «Send a TG message to PM». նախագծի ղեկավարին Telegram հաղորդագրություն է ուղարկում՝ տեղեկացնելու, որ ներկայացումը չի ընդունվել Project ID-ների անհամապատասխանության պատճառով։

17. «Send a message to PM». էլ. փոստով տեղեկացնում է նախագծի ղեկավարին անհամապատասխանության մասին։

18. «Mismatching Project IDs». սխալ է տալիս և դադարեցնում ամբողջ աշխատանքային հոսքը։

Այնուհետև, եթե Project ID-ի ստուգման ընթացակարգերը հաջողությամբ անցնում են, աշխատանքային հոսքը շարունակում է կատարումը։

Քանի որ ներկայացվում են մի քանի ենթահամակարգ, և յուրաքանչյուրը պետք է ստուգվի, օգտագործում ենք «Loop over Items1» հանգույցը, որն աշխատանքային հոսքը կատարում է յուրաքանչյուր ենթահամակարգի համար առանձին (տե՛ս Նկար 1)։

Այսպիսով, յուրաքանչյուր ենթահամակարգ փոխակերպվում և պատճենվում է Google Sheets ձևաչափով (տե՛ս Նկար 8)՝

Այսպիսով, «Convert BOM to GSheets/ Copy BOM» հանգույցը, որը մտնում է «Loop over Items1» ալգորիթմի մեջ (տե՛ս Նկար 1), ըստ էության, աշխատանքային հոսքի նախորդ տարբերակի առաջին մասն է (տե՛ս Նկար 3)։ Այս աշխատանքային հոսքը գործարկվում է ծնող (հիմնական) աշխատանքային հոսքի կողմից և կատարվում որպես դրա մաս։ Նույնը վերաբերում է մնացած ենթահոսքերին։

Այնուհետև սահմանվում է պայմանական ձևաչափումը (տե՛ս Նկար 9)՝

Դրանից հետո ենթահոսքերը ստուգվում են ձևանմուշի պահանջներին համապատասխանության համար (տե՛ս Նկար 10)՝

Այն բանից հետո, երբ բոլոր ենթահամակարգերն անցել են Project ID-ի և ձևանմուշի ստուգումները, աշխատանքային հոսքը պետք է ավարտվի՝ նշելով ներկայացման կարգավիճակը և տեղեկացնելով նախագծի ղեկավարին (կամ ձևի ներկայացման համար պատասխանատուին), թե արդյոք այն հաջող էր, և ներկայացումների տվյալների բազայում սահմանվում է TRUE կարգավիճակ, թե նա պետք է ուղղի ենթահամակարգերը և նորից ներկայացնի։ Այդ դեպքում սահմանվում է FALSE կարգավիճակ (տե՛ս Նկար 11)։ TRUE և FALSE արժեքների նշումը թույլ կտա մեզ հաջողությամբ իրականացնել հաջորդ քայլը։

Խնդիր 3. ինժեների կողմից անվավեր BOM-ը նորից ներկայացնելու գործընթացը կարող է շատ ժամանակ խլել, կամ նա կարող է նույնիսկ մոռանալ դրա մասին։

Ուստի մենք նշեցինք TRUE և FALSE ներկայացումները՝ կրկնակի ներկայացումների վերլուծությունը հեշտացնելու համար։

Ինչպես տեսնում եք Նկար11-ում, աշխատանքային հոսքին ավելացվել են նաև Telegram հաղորդագրություններ։ Սա արվել է ավելի բարձր արդյունավետություն ապահովելու համար, քանի որ եթե աշխատակիցը կարող է բաց թողնել էլ. նամակը, Telegram-ի դեպքում դա, հավանաբար, ավելի հազվադեպ կպատահի՝ դրանով մասամբ լուծելով Խնդիր 1-ը։

Այս պարզ գործողության ազդեցությունը արդյունավետության և արդյունավետ աշխատանքի վրա նվազագույնի հասցնելու համար ստեղծվել է առանձին հիշեցման աշխատանքային հոսք։ Այն կարող եք տեսնել ստորև (տե՛ս Նկար 12)։

Հիշեցման աշխատանքային հոսքն աշխատում է ներկայացումների փաստաթղթի հետ (տե՛ս Նկարներ 6(a), (b), (c), (d))։ Այն նախատեսված է աշխատակցին հիշեցնելու BOM-ը նորից ներկայացնել, եթե անվավեր տարբերակի ներկայացումից անցել է ավելի քան 24 ժամ։ Եթե անվավեր BOM-ը 48 ժամից ավելի չի վերբեռնվում, կապ են հաստատում աշխատակցի ղեկավարի հետ, որպեսզի նա հիշեցնի իր աշխատակցին ներկայացնել BOM-ը։

Տրամաբանությունն ըստ հանգույցների՝

1. «Schedule Trigger». այս հանգույցը կարգավորված է աշխատանքային հոսքը գործարկելու (կատարելու) ամեն ժամ։

2. «Get row(s) in sheet». այս հանգույցը ներկայացումների փաստաթղթից դուրս է բերում ներկայումս գոյություն ունեցող բոլոր տողերը՝ հետագա կատարման համար։

3. «Last submission per ProjectID». սա JavaScript կոդ է, որը թողնում է միայն յուրաքանչյուր տողի վերջին ներկայացումը։ Սա արվում է ամենաթարմ ներկայացման հետ աշխատելու համար՝ ստուգելով, թե արդյոք ներկայացումից անցել է >24 կամ >48 ժամ, թե ոչ։

4. «Leave only FALSE status». հանգույցը տողերը զտում է այնպես, որ հետագայում մշակվեն միայն FALSE ներկայացումները (անվավեր BOM ներկայացումները), իսկ եթե FALSE տողեր չկան, այն դադարում է։

Այնուհետև աշխատանքային հոսքը բաժանվում է 2 ճյուղի՝

>24 ժամ, բայց <48 ժամ առաջ ներկայացված տողերի ճյուղ (վերին ճյուղ (տե՛ս Նկար 4))՝

1. «Submitted >24H & <48H + Reminder sent >24H». ևս մեկ JavaScript կոդ, որը թողնում է միայն այն ներկայացումները, որոնք բավարարում են հետևյալ պայմաններին՝ a. Ներկայացվել է ավելի քան 24 ժամ առաջ, բայց 48 ժամից պակաս առաջ. b. Հիշեցումն ուղարկվել է > 24 ժամ առաջ կամ ընդհանրապես չի ուղարկվել։ Եթե այս փուլում կան տողեր, որոնք ունեն այս 2 հատկանիշները, ապա դրանցից յուրաքանչյուրին պետք է հիշեցում ուղարկվի։

2. «Set reminder email Timestamp». այս հանգույցը մուտք է գործում Google Sheets ներկայացումների փաստաթուղթ և որոշակի տողերի համար լրացնում «Reminder sent at» սյունակը։ Սա օգտագործվում է ստուգելու՝ արդյոք հիշեցում ուղարկելու ժամանակն է, թե ոչ։ Օրինակ՝ այն օգտագործվում է նախորդ հանգույցում (այսինքն՝ Submitted >24H & <48H + Reminder sent >24H)՝ (b) պայմանը ստուգելու համար, քանի որ հակառակ դեպքում հիշեցումը կուղարկվեր ամեն ժամ (այսինքն՝ ամեն անգամ, երբ աշխատանքային հոսքը կատարվում է)։

3. «Telegram message to PM». այս հանգույցը Telegram բոտի միջոցով հիշեցում է ուղարկում նախագծի ղեկավարին (այսինքն՝ աշխատակցին, որն ի սկզբանե ներկայացրել է BOM-ը)։

4. «Send a Reminder to PM». էլ. փոստի հանգույց, որը հիշեցումը նախագծի ղեկավարին ուղարկում է նաև էլ. փոստով։

>48 ժամ առաջ ներկայացված տողերի ճյուղ (ստորին ճյուղ (տե՛ս Նկար 4))՝

1. «Submitted >48H ago + Reminder email >24H». JavaScript կոդ, որը բավարարում է հետևյալ պայմաններին՝ a. Ներկայացումը տեղի է ունեցել ավելի քան 48 ժամ առաջ։

   b. Հիշեցման նամակն ուղարկվել է ավելի քան 24 ժամ առաջ։ Եթե տողն այս փուլում բավարարում է այս գործոններին, նշանակում է՝ նախագծի ղեկավարն անտեսել է հիշեցումը, և ժամանակն է դիմել նրա ղեկավարին։

2. «Set reminder email Timestamp1». ինչպես մյուս ճյուղում, սա լրացնում է «Reminder sent at» սյունակը՝ գրանցելով ընթացիկ ժամանակային դրոշմը։ Թույլ է տալիս հիշեցումներ ուղարկել պատշաճ ժամանակին, ոչ թե ամեն ժամ։

3. «Send a Message to a Manager». էլ. փոստի հանգույց, որը հաղորդագրություն է ուղարկում ղեկավարին՝ խրախուսելով նրա շփումը աշխատակցի հետ՝ BOM-ը նորից ներկայացնելու համար։

4. «Email to PM about reaching out a manager». ևս մեկ էլ. փոստի հանգույց, որը աշխատակցին տեղեկացնում է, որ դիմել են ղեկավարին՝ BOM-ի կրկնակի ներկայացումը խրախուսելու համար։

Այսպիսով, հիշեցման աշխատանքային հոսքի ներդրմամբ կրկնակի ներկայացումը բաց թողնելը դառնում է գրեթե անհնար՝ ապահովելով ավելի բարձր արդյունավետություն, արդյունավետ աշխատանք և արտադրողականություն։

Եզրափակելով՝ այս քայլում մենք ապահովեցինք, որ FALSE BOM/ենթահամակարգի ներկայացումը բաց չի թողնվի կամ անտեսվի. հիշեցումներն ավտոմատ կուղարկվեն աշխատակցին և նրա ղեկավարին։

Ավելին, աշխատանքային հոսքը նախագծված է այնպես, որ մուտքային տվյալները, որոնք աշխատանքային հոսքի հաջող կատարման հիմքն են, լինեն ճիշտ։ Հետևաբար, այն նպաստում է ընկերության ավելի բարձր արդյունավետությանը, արդյունավետ աշխատանքին և արտադրողականությանը։

Բացի այդ, ենթահոսքերի կիրառմամբ բարելավվել է աշխատանքային հոսքի ընթեռնելիությունը։

Եվ վերջապես, մենք բարելավեցինք աշխատանքային հոսքի հնարավորությունները՝ թույլ տալով միաժամանակ ներկայացնել նույն նախագծի մի քանի BOM/ենթահամակարգ։

2025 թվականի դեկտեմբերի 25-ին շրջանառության մեջ դրվեց «Engineering City»-ին նվիրված նամականիշ։

380 AMD անվանական արժեքով նամականիշի վրա պատկերված են Engineering City-ն, ինչպես նաև Engineering City-ի լոգոն և «ENGINEERING CITY» մակագրությունը հայերեն և անգլերեն։

Շիրակացու դպրոցի լեզվի և գրականության բաժնից։

Ես շատ եմ հպարտանում, որ մենք՝ հայերս, ունենք եզակի հայոց լեզու, որը թույլ է տալիս մեզ գոյատևել դարերի բուռն հոսքում։ Թեև որոշ հայեր ակտիվ ներդրում են ունեցել գիտության և ճարտարագիտության վերջին 2 դարերի բուռն զարգացման մեջ, հայերի ընդհանուր ազդեցությունը շատ փոքր է, և այդ ներդրողները միշտ չէ, որ ներկայացնում են Հայաստանը և, ավելին, չեն հանդես գալիս որպես հայերենում նոր տերմինաբանության շարժիչ ուժ։

Ուրախ եմ տեսնել, որ նախաձեռնություն կա հայոց լեզուն մաքուր պահելու նաև ճարտարագիտության մեջ, բայց երբեմն ամեն ինչ իմաստային առումով հայերեն թարգմանելու փորձը շփոթություն է առաջացնում և հետևաբար չի ներկայացնում օտար համարժեքի ամբողջական իմաստը, հատկապես եթե այդ բառի հիմքը միջազգայնորեն ընդունված է։ Լավ է ունենալ հատուկ բառեր այն տերմինների համար, որոնք գալիս են դարերի միջով և ինչ-որ կերպ օգտագործվել են հայերի կողմից իրենց ավանդական կենսակերպում։

Բայց կան բառեր՝ տերմիններ, որոնք սովորաբար օգտագործվում են որոշակի գիտական կամ ճարտարագիտական իմաստներ ներկայացնելու համար, և լեզվաբանների կողմից թարգմանվելով՝ դրանք դառնում են անիմաստ։

Կամ լեզվաբանները պետք է աշխատեն ոլորտի մասնագետների հետ՝ այդ բառերը ստեղծելու կամ թարգմանելու համար։ Ես, այնուամենայնիվ, կառաջարկեմ պահպանել որոշակի բառերի միջազգային արմատը՝ հատուկ մասնագիտական խոսքում օգտագործելիս շփոթությունից խուսափելու համար, և դա չպետք է դիտվի որպես լեզվի աղտոտում։

Good example of Armenian equivalents: Արգանակ, եզրաքար...

Վատ օրինակներ, հատկապես ճարտարագիտական բովանդակության համար՝

Կուտակիչ - accumulator (ակումուլյատոր). այս բառը կարող է կիրառման շատ դեպքեր ունենալ, ուստի պետք է համապատասխանաբար օգտագործվի

պահոց - archive not every "պահոց" is archive and not every "archive" is պահոց

սաթիկ – electron

լուսիկ- photon