Во многих наших компаниях в EC работают аспиранты. Но, по моим наблюдениям, эти аспиранты редко проводят исследования для компаний, в которых работают. Вместо этого их темы определяют профессора в университетах.

Но это досадно и означает упущенную возможность.

Аспиранты-инженеры занимаются исследованиями технологий будущего. Исследования технологий будущего должны стать ядром новых продуктов компаний, в которых они работают.

Компании должны сотрудничать с университетскими профессорами в определении исследовательских проектов для аспирантов.

Иначе это будут упущенные возможности для компаний.

Мы продолжаем совершенствовать рабочий процесс, автоматизирующий передачу BOM. Текущий полный рабочий процесс показан на рисунке ниже (см. рисунок 1). Внешне он сильно изменился, но на самом деле логика осталась прежней.

На этом этапе мы решили ряд проблем, связанных с эффективным управлением временем и проверкой данных, научили рабочий процесс выполнять более сложные задачи и поработали над его читаемостью.

Итак, эта версия рабочего процесса выглядит намного проще, чем версия из предыдущей статьи. Здесь мы использовали подпроцессы (Sub-workflows). Это отдельные рабочие процессы внутри большего. Подпроцессы на рисунке 1 — это узлы со значками, показанными на рисунке 2.

Теперь каждый подпроцесс (значок как на рисунке 2) является частью рабочего процесса предыдущей версии. Мы вернёмся к этому позже.

Проблема 1: BOM проекта может содержать до 15 подсистем (под-BOM), которые находятся в отдельных файлах (все они относятся к одному Project ID), поэтому все они должны быть обработаны рабочим процессом. Это вызывает другую проблему:

Проблема 2: Project ID — основа информации, обрабатываемой рабочим процессом, поэтому нам нужно убедиться, что отправляется правильный Project ID.

Прежде всего, общее у подсистем то, что они относятся к одному проекту (Project ID один и тот же). Поэтому Project ID логично взять за основу для решения этой задачи. Итак, мы начали с создания базы данных Project ID в той же таблице Google Sheets (см. рисунок 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, отправленный через форму, с Project ID, указанным в BOM (каждой подсистемы), тем самым гарантируя, что отправлен правильный 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»: этот узел просто извлекает данные, включая Project ID, из файла BOM.

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»: этот узел отправляет напоминание руководителю проекта (т. е. сотруднику, который изначально отправил BOM) через Telegram-бота.

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.

Итак, с введением рабочего процесса напоминаний пропустить повторную отправку становится практически невозможно, что обеспечивает более высокую результативность, эффективность и продуктивность.

В заключение, на этом шаге мы обеспечили, что отправка BOM/подсистемы со статусом FALSE не будет пропущена или проигнорирована: напоминания будут автоматически отправляться сотруднику и его/её руководителю.

Более того, рабочий процесс спроектирован так, чтобы входные данные, на которых основано успешное выполнение рабочего процесса, были корректными. Тем самым он способствует большей результативности, эффективности и продуктивности компании.

Кроме того, за счёт использования подпроцессов улучшена читаемость рабочего процесса.

И последнее по порядку, но не по значению: мы расширили возможности рабочего процесса, позволив одновременно отправлять несколько BOM/подсистем для одного проекта.

25 декабря 2025 года в обращение была выпущена марка, посвящённая «Engineering City».

На марке номиналом 380 AMD изображены Engineering City, а также логотип Engineering City и надпись «ENGINEERING CITY» на армянском и английском языках.

От кафедры языка и литературы школы Ширакаци.

Я очень горжусь тем, что у нас — армян — есть уникальный армянский язык, который позволяет нам выживать в бурном потоке веков. Хотя некоторые армяне активно участвовали в бурном развитии науки и техники последних 2 столетий, общее влияние армян очень невелико, и эти участники не всегда представляют Армению и, более того, не выступают двигателями новой терминологии на армянском языке.

Я рад видеть, что есть инициатива сохранять чистоту армянского языка и в инженерии, но иногда попытка перевести всё на армянский по смыслу вносит путаницу и потому не передаёт полного значения иностранного эквивалента, особенно если основа этого слова принята на международном уровне. Хорошо иметь особые слова для терминов, которые пришли сквозь века и так или иначе использовались армянами в их традиционном укладе жизни.

Но есть слова — термины, которые обычно используются для обозначения определённых научных или инженерных понятий, и перевод их лингвистами лишает их смысла.

Либо лингвистам следует работать со специалистами отрасли, чтобы создавать или переводить такие слова. Я всё же рекомендую сохранять международный корень определённых слов, чтобы избежать путаницы при их использовании в специальной профессиональной речи, и это не следует считать засорением языка.

Хороший пример армянских эквивалентов: Արգանակ, եզրաքար...

Плохие примеры, особенно для инженерного контента:

Կուտակիչ - accumulator (аккумулятор): у этого слова может быть очень много вариантов применения, поэтому его следует использовать соответственно

պահոց - archive (архив): не каждый «պահոց» — архив, и не каждый «archive» — պահոց

սաթիկ – electron (электрон)

լուսիկ- photon (фотон)