Վտանգավոր է դառնում ԱԲ-ն ամեն ինչում չներգրավելը։

Որքան շատ է ԱԲ-ն ներգրավված, որքան բազմազան է այդ ներգրավումը և որքան տարածված է կազմակերպության բոլոր ստորաբաժանումներում, այնքան բարձր է կազմակերպության մրցակցային առավելությունը։ Մյուս կողմից՝ որքան քիչ է ԱԲ-ն տարածված կազմակերպությունում, այնքան մեծ է կազմակերպության գոյատևման սպառնալիքը։

Ո՞վ պետք է ղեկավարի ԱԲ-ի այս տարածումը։ Սկզբում այս վերափոխումը ղեկավարում են ԱԲ-ի խանդավառներն ու ջատագովները։ Բայց ինչ-որ պահի ստորաբաժանումների ղեկավարները պետք է ստանձնեն իրենց ստորաբաժանումներում ԱԲ-ի լիարժեք ներգրավման պատասխանատվությունը։

S-կորերի վրա այս գործընթացն այսպիսին է՝

Եվ վերջապես, ստեղծվել է Telegram ալիք «AI Community – Engineering City» անվանումով։ Խորհուրդ եմ տալիս բոլորին միանալ այնտեղ EC-ի ԱԲ համայնքին։

Նախորդ հոդվածում ասացինք, որ «ԱԲ-ն պետք է լինի ամենուր»։

Այժմ ուզում ենք ավելացնել՝ «Աշխատանքային հոսքերի ավտոմատացումը պետք է լինի ամենուր»։

Եվ գոյատևման հրահանգը դառնում է՝

«ԱԲ + աշխատանքային հոսքերի ավտոմատացում ամենուր»,

կամ

«ԱԲ + WFA ամենուր»,

որտեղ WFA-ն նշանակում է աշխատանքային հոսքերի ավտոմատացում (Workflow Automation)

Կազմակերպության մակարդակում այն կունենար այսպիսի տեսք՝

Ցանկացած ավտոմատացման նպատակը կազմակերպությունների համար ազատ ժամանակ ստեղծելն է։ Կազմակերպություններին ազատ ժամանակ է պետք, որպեսզի այն ծախսեն նոր արտադրանքների հետազոտության և մշակման վրա։ Որքան շատ ազատ ժամանակ կարող է ստեղծել կազմակերպությունը, այնքան շատ կարող է ծախսել նոր արտադրանքների հետազոտության և մշակման վրա։ Հետևաբար, հետազոտությունից և մշակումից բացի ամեն ինչ պետք է ավտոմատացվի։

Բանաձևը, որին ձգտում են կազմակերպությունները, հետևյալն է՝

TR&D →  TWorkflow → 0 

Այստեղ TR&D-ն այն ժամանակն է, որը կազմակերպությունները կարող են իրենց թույլ տալ ծախսել հետազոտության և մշակման վրա, իսկ Tworkflow-ն այն ժամանակն է, որը կազմակերպությունները պետք է ծախսեն մնացած ամեն ինչի վրա։

Աշխատանքային հոսքերի ավտոմատացման ծրագրային ապահովումն այնպիսի ծրագիր է, որը կազմակերպություններին ազատում է աշխատանքային գործընթացների վրա ժամանակ ծախսելուց, այսինքն՝ այդ ժամանակը հասցնում է զրոյի՝ TWorkflow → 0։

Աշխատանքային հոսքերի ավտոմատացումն ինքնին նոր չէ։ Այն վաղուց է գոյություն ունի։ Բայց վերջերս երկու բան է տեղի ունեցել՝ ծրագրային ապահովումը դարձել է շատ հեշտ օգտագործվող (այժմ յուրաքանչյուրը կարող է ավտոմատացման ծրագիր ստեղծել), և ԱԲ-ն հասանելի է դարձել բոլորին։

Աշխատանքային հոսքերի ավտոմատացման համար առաջարկվել է երկու ծրագրային փաթեթ։ Երկուսն էլ կարող են ԱԲ-ն ներառել ավտոմատացման գործընթացում՝

1. n8n (n8n.io)

2. Make.com (make.com)

Երկուսն էլ հեշտ են օգտագործման համար, սակայն n8n-ն ավելի կատարելագործված փաթեթ է, որը կարող է ավտոմատացնել ավելի բարդ աշխատանքային հոսքեր։ Դրա առաջադեմ օգտագործումը պահանջում է ծրագրավորման որոշ հասկացությունների իմացություն։ Այն կառաջարկեի ծրագրավորման հմտություններ ունեցողներին։ Make.com-ը n8n-ից էլ ավելի հեշտ է օգտագործման համար, բայց թույլ չի տալիս ավելի բարդ աշխատանքային հոսքեր։ Այն ծրագրավորում չի պահանջում, ուստի կառաջարկեի այն բոլոր ոչ ծրագրավորողներին։ Դրանով սկսելը նույնպես ավելի հեշտ է։

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

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

Հետևաբար, միանգամայն բնական է, որ լուծումներ առաջարկող ընկերություններում ինժեներները դառնում են BDM-ներ, և դա պետք է խրախուսել։

Գուցե ցանկանաք կարդալ նաև «Արտադրանքի վաճառք, լուծումների վաճառք և ծառայությունների վաճառք» հոդվածը (EC Journal 19/2023)։

Տեխնոլոգիական տնօրենը (CTO՝ Chief Technology Officer) այն անձն է, որը պատասխանատու է երեք հիմնական բանի համար՝

1. Ընկերության օգտագործած հիմնական տեխնոլոգիաների սահմանում։

2. Նոր տեխնոլոգիաների մշտական որոնում։

3. Նոր տեխնոլոգիաների ներդրում ընկերությունում։

Տեխնոլոգիաները կարելի է դասակարգել տարբեր խմբերի, օրինակ՝

1. Ընկերության արտադրանքներում օգտագործվող տեխնոլոգիաներ։ Օրինակ՝ CTO-ն կարող էր NI տեխնոլոգիաները սահմանել որպես ընկերության արտադրանքներում օգտագործվող հիմնական տեխնոլոգիա՝ PXI հարթակ, cRIO հարթակ, …

2. Ընկերության արտադրանքների մշակման մեջ օգտագործվող մասնագիտական տեխնոլոգիաներ։ Օրինակ՝ LabVIEW, Altium Designer և SolidWorks։

3. Ընկերության արտադրած տեխնոլոգիաներ։

4. Արտադրողականության տեխնոլոգիաներ։ Սրանք գրասենյակային և գործընթացային գործիքներն են, օրինակ՝ MS Office, Google-ի ծառայություններ, աշխատանքային հոսքերի ավտոմատացման տեխնոլոգիաներ, համակարգիչների ապրանքանիշեր, …

Քանի որ տեխնոլոգիաները մեծ մասամբ որոշում են ընկերության արտադրանքների արդյունավետությունը և ընկերության արտադրողականությունը, դա նշանակում է, որ CTO-ն պատասխանատու է և՛ արդյունավետության, և՛ արտադրողականության համար։

Երրորդ պարտականությունը (նոր տեխնոլոգիաների ներդրումը ընկերությունում) ամենադժվարն է։ Դա այն պատճառով, որ այստեղ CTO-ն կբախվի բոլոր աշխատակիցների հսկայական դիմադրությանը։ Ինչո՞ւ։ Որովհետև աշխատակիցները յուրացրել են հին տեխնոլոգիաները և օգտագործում են դրանք իրենց առօրյա աշխատանքում։ Ծայրահեղ դեպքում նոր տեխնոլոգիայի ներդրումը կարող է նշանակել հին տեխնոլոգիայից լիովին հրաժարվել և նորը սովորել։ Բայց ոչ միայն դա. նոր տեխնոլոգիաները նաև նոր գործընթացներ են բերում։

Դիմադրությունը կարող է հսկայական լինել։ Բայց մյուս կողմից՝ եթե CTO-ին չհաջողվի իրականացնել այս անցումները, ընկերությունը կորցնում է իր մրցակցային առավելությունը մրցակիցների նկատմամբ և ի վերջո մահանում է՝ իր հետ տանելով բոլոր այն աշխատակիցներին, որոնք դիմադրում էին նոր տեխնոլոգիային անցնելուն։

Ստորև նկարը կատարելապես արտացոլում է այս պատկերը։

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

S-կորերի վրա այս գործընթացն այսպիսին է՝

ԱԲ-ի և աշխատանքային հոսքերի ավտոմատացման տեխնոլոգիաների ներդրումն ընկերությունում հենց այս տեսակից է։

«Ուսանո՞ղ ունեք» հարցը կարելի է վերաձևակերպել այսպես՝ «Ապրո՞ւմ եք ապագայում»։

Երբ կենտրոնանում ենք միայն ընթացիկ նախագծի վրա, ապրում ենք ներկայում՝

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

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

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

Այստեղ ենթադրվում է, որ՝

1. Ուսանողները կարող են նոր տեխնոլոգիական հմտություններ յուրացնել ավելի արագ, քան մասնագետները,

2. Ավագ դպրոցի աշակերտներն ապագան ավելի լավ են տեսնում, քան մեծահասակները։

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

Իմաստը նրանց սովորեցնելը ՉԷ, այլ նրանց ներգրավելը։ Մենք պետք է հարցնենք նրանց, ոչ թե նրանք՝ մեզ։ Մենք պետք է դա անենք մեր օգտի համար, պետք է դա անենք ապագայի շուկաներում մրցակցային առավելություն ձեռք բերելու համար։ Իմաստը նրանց միջոցով ապագան տեսնելն է։

Համաձա՞յն եք այս հոդվածի հետ։

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

Կարծում ենք, որ հետևյալ տարրերը պետք է առկա լինեն EC-ում տրվող յուրաքանչյուր նախագծում՝ սա ներառում է «Բագրևանդ 21» նախագծերը, պրակտիկայի նախագծերը, կուրսային աշխատանքները և դիպլոմային նախագծերը։ Նույնիսկ ավագ դպրոցի նախագծերը պետք է դրանք ունենան։ Ահա դրանք՝

1. Ամբողջական խնդրի դրվածք

2. Տեխնոլոգիական հետազոտություն

3. AI

4. Թիմային նախագիծ

5. Մի քանի տարիքային խմբեր

Ստորև ներկայացված է այս տարրերից յուրաքանչյուրի նկարագրությունը՝

1. Նախագիծը պետք է սկսվի ամբողջական խնդրի դրվածքով։ Ամբողջական խնդրի դրվածքը պարզապես տեխնիկական պահանջները չեն։ Այն ներառում է խնդրի դրվածքի համատեքստը, թե ինչու է այն ի հայտ եկել, ինչ ճգնաժամ կամ սահմանափակումներ պետք է լուծի, խնդրի դրվածքի պատմությունը (այսինքն՝ ինչ նախորդ խնդրի դրվածքներ են լուծվել նախքան ընթացիկին հասնելը, խնդրի դրվածքների էվոլյուցիայի միտումը, հնարավոր հաջորդ խնդրի դրվածքը)։ Խնդրի դրվածքը պետք է լինի ընկերությանը հատուկ։ Այն պետք է ցույց տա, թե ինչպես է տեղավորվում ընկերության շուկայական ռազմավարության, մրցակցության, բիզնես կողմի, տնտեսական կողմի մեջ, …։ Կարճ ասած՝

   խնդրի դրվածքը և դրա լուծումը պետք է լինեն ընկերության պլանի մաս, և աշխատանքը պետք է օգուտ բերի այն ընկերությանը, որտեղ նախագիծը տրվում և իրականացվում է։ (Խնդրում ենք կարդալ նաև ««-3 +1» մեթոդաբանությունը խնդրի դրվածքի ձևակերպման մեջ» (EC Journal 11/2025) հոդվածը)։

2. Նախագիծը պետք է այս կամ այն ձևով ներգրավի ԱԲ-ն։ ԱԲ-ն ներգրավելու վայրերից մեկը լուծման որոնման փուլն է։ (Խնդրում ենք կարդալ նաև «Ենթադրություններ «դիպլոմային աշխատանքների» մասին ԱԲ-ի դարաշրջանում» (EC Journal 9/2025) հոդվածը)։

3. Յուրաքանչյուր նախագիծ պետք է հասնի POC-ի և նախատիպավորման փուլերին։ Դա պետք է հնարավոր լինի նախագծում ԱԲ-ն ներգրավելուց խնայված հսկայական ժամանակի շնորհիվ։ Միասին վերցրած (POC + Նախատիպ)՝ սա տեխնոլոգիական հետազոտության փուլն է, որի համար ստեղծվել է ARC-ն (Առաջատար հետազոտությունների կենտրոնը)։ Սա պետք է օգուտ բերի այն ընկերություններին, որտեղ ուսանողն իրականացնում է իր նախագիծը։ Միայն այս փաստը պետք է ընկերություններին հետաքրքրի ուսանողներին իրենց նախագծերում ընդգրկելու հարցում։

4. Ուսանողը պետք է աշխատի տարբեր մասնագիտությունների (մեխանիկա, էլեկտրոնիկա, ներկառուցված համակարգեր, կառավարում, ծրագրային ապահովում, արտադրություն, …) թիմում։ Այլ կերպ ասած՝ նախագիծը պետք է ավելի մեծ լինի, քան ուսանողի մասը։ Ուսանողը պետք է տեսնի, որ ինժեներական նախագծերն ամբողջական նախագծեր են, որտեղ ներգրավված են բազմաթիվ ինժեներական մասնագիտություններ։ Սա ուսանողին ցույց կտա, որ նա նախագծային թիմի անդամ է, որտեղ մարդիկ հենվում են միմյանց վրա և կախված են միմյանցից՝ նախագծի ընդհանուր նպատակներին հասնելու համար։ Սա ինքնին մեծ կրթական արժեք ունի։ Սա ուսանողների մտքում կզարգացնի համակարգային տեսլականը։

5. Նախագծային թիմը պետք է լինի բազմասերունդ։ Այսինքն՝ այն պետք է ունենա տարբեր տարիքային խմբեր, ներառյալ ավագ դպրոցի աշակերտներ։ Իդեալական նախագծում միասին աշխատում են մասնագետ ինժեներներ, համալսարանների ուսանողներ և ավագ դպրոցի աշակերտներ՝ յուրաքանչյուրը նպաստելով իր կարողության չափով։

Այս տարրերի մեծ մասը պետք է առկա լինի նախագծում, որպեսզի այն կոչվի EC նախագիծ։ Հակառակ դեպքում նախագիծը պարտադիր չէ իրականացնել EC-ում։

Կարճ ասած՝ ուսանողական նախագիծը պետք է լինի մասնագիտական, առևտրային նախագծի միկրոտիեզերք։ Ուսանողը պետք է տեսնի ինժեներական նախագծի բոլոր չափումներն ու տեսանկյունները։ (Խնդրում ենք կարդալ նաև «Առևտրային արտադրանքի տարբեր տեսանկյունները». EC Journal 11/2025) հոդվածը)։

Հարգելի՛ EC համայնք,

Տեղեկացնում ենք մեր հաջորդ EC հանդիպման օրվա մասին, որը տեղի կունենա օգոստոսի 8-ին (մեկ ամսից)։

Այս հանդիպման թեման կլինի «ԱԲ-ն EC-ում»։

Յուրաքանչյուր ընկերությանը խնդրում ենք ներկայացնել, թե ինչպես է օգտագործում կամ մտադիր է օգտագործել ԱԲ-ն իր աշխատանքում։

Ահա անցած տարիների հանդիպումների թեմաները՝

2023։ Ընկերությունների ներկայացում։ Յուրաքանչյուր ընկերություն ներկայացավ համայնքին։

2024։ ARC-ի ներկայացում։ Բաժանվեցինք քննարկման խմբերի՝ ARC-ի յուրաքանչյուր լաբորատորիայում հնարավոր հետազոտական նախագծերի վերաբերյալ։

2025։ ԱԲ-ն EC-ում։ Այս տարի։

Շնորհակալություն, Ինժեներական ասոցիացիա