Становится опасно не привлекать ИИ ко всему.

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

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

На 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. В этом году.

Спасибо, Инженерная ассоциация