Обучение IT-специалистов начинается с технологий: языки программирования, архитектура, инфраструктура, информационная безопасность, сертификации, новые платформы, новые инструменты. Это логично, но профессионального развития исключительно в своей предметной области недостаточно. В большинстве IT-компаний разработчик не только пишет код. Он также инженер, архитектор, аналитик, специалист технической поддержки, руководитель проекта, менеджер технической команды, эксперт, который участвует во встречах с клиентом, помогает сформулировать задачу, объясняет сложные решения простым языком и отвечает за то, чтобы технология действительно заработала в бизнес-процессе.
Поговорим о том, какие навыки стоит развивать профессионалам, когда IT-рынок меняется.
Эффективная коммуникация как часть инженерной культуры
Кажется, что для технического эксперта главное – глубина знаний, способность быстро найти решение, настроить систему, разобраться в архитектуре. Это действительно основа профессии, но любая технология внедряется людьми и для людей. Чтобы проект состоялся, нужно понять запрос бизнеса, снять ожидания клиента, договориться с коллегами, аргументировать техническое решение, объяснить риски, пройти через конфликтную ситуацию и при этом не разрушить отношения. В этом смысле коммуникация перестает быть «приятным дополнением» к профессии, и становится рабочим инструментом.
Особенно это заметно в клиентских проектах. IT-специалист может прекрасно разбираться в решении, но если он не умеет задавать уточняющие вопросы, слышать разные типы собеседников, переводить техническую логику на язык бизнес-результата, проект начинает буксовать. Где-то возникает недопонимание, где-то клиент ждет одного, команда делает другое, где-то конфликт можно было снять на раннем этапе, но его просто не распознали.
Поэтому в развитии IT-команд важно учить не абстрактному «умению общаться», а вполне прикладным вещам: как выстраивать диалог, как работать с возражениями, как презентовать решение, как вести сложный разговор, как понимать разные типы личности и подбирать формат взаимодействия под конкретного человека. Для технического специалиста это такой же навык, как и умение работать с системой.
Проектное мышление: видеть путь от задачи до результата
Для инженеров, архитекторов, аналитиков и технических руководителей это особенно значимо, потому что большая часть их деятельности строится вокруг проектов разной сложности и длительности. Проектное мышление помогает специалисту видеть не только свою часть работы, но и весь маршрут: что должно быть на входе, какие этапы предстоит пройти, где возможны риски, кто влияет на результат, какие сроки реалистичны, какие договоренности нужно зафиксировать заранее. Это сильно повышает качество работы, потому что специалист начинает мыслить не отдельной задачей, а конечным эффектом.
В IT-сфере это критично. Один проект может быть коротким и понятным, другой – длинным, многоуровневым, с большим количеством участников и зависимостей. И если технический эксперт умеет управлять только своим участком, но не видит общей логики, команде сложнее удерживать сроки, качество и ожидания заказчика.
Здесь обучение должно быть привязано к роли, специалист технической поддержки больше взаимодействует с клиентом напрямую, поэтому для него особенно важны коммуникация, клиентский сервис, стрессоустойчивость, способность быстро разбираться в запросе. Инженер или архитектор, который участвует в проектировании инфраструктуры, должен дополнительно понимать этапность проекта, зависимость решений, логику согласований, управление рисками. Руководителю технической команды нужен следующий уровень – управление людьми.
Когда специалист становится руководителем, уровень сложности резко меняется. Раньше он отвечал в первую очередь за себя и свои задачи, теперь нужно управлять людьми, мотивацией, развитием, конфликтами, ожиданиями и командной динамикой. Это отдельная профессия внутри профессии, техническая глубина помогает руководителю быть авторитетным, но не заменяет управленческие навыки. Нужно понимать цикл менеджмента, основы ситуационного лидерства, разные стили управления и как они связаны с уровнем зрелости сотрудников. Одному человеку нужна подробная постановка задачи и сопровождение, другому больше автономии, третьему – помощь в мотивации, четвертому – честная обратная связь.
Для IT-команд это особенно важно, потому что специалисты часто ценят профессиональную свободу, уважение к экспертизе и честный диалог. Управлять такой командой директивно и одинаково для всех невозможно, руководитель должен видеть, кто на каком этапе находится, кому нужно дать больше поддержки, кому – больше ответственности, а где важно вовремя заметить выгорание или потерю вовлеченности. Поэтому управленческое обучение для IT-специалистов должно включать не только планирование и контроль, но и мотивацию, принятие решений, управленческое влияние, построение эффективной команды, развитие сотрудников и работу с обратной связью.
Обучение работе с искусственным интеллектом
Здесь важно разделять несколько направлений:
- Базовая ИИ-грамотность для сотрудников. Людям нужно понимать, что это за инструменты, как их можно применять в ежедневной работе, какие задачи они помогают ускорять, где дают хороший эффект, а где требуют осторожности. Для этого проводятся обучающие марафоны и дистанционные курсы, где сотрудники могут разобраться с темой на практическом уровне.
- ИИ как решение для бизнеса. Здесь обучение требуется тем, кто продает, проектирует, внедряет и сопровождает такие решения: аккаунт-менеджерам, инженерам, архитекторам, проектным командам. Им важно понимать, какие бизнес-задачи решает ИИ, как технология встраивается в процессы клиента, какую ценность создает, какие ограничения имеет и как объяснять это заказчику.
- Использование ИИ внутри собственных процессов. Это уже про зрелость организации: где ИИ может помочь в оценке, обучении, создании курсов, анализе данных, подготовке материалов, оптимизации повторяющихся операций. Здесь компании во многом идут через исследование, тестирование и постепенное внедрение, потому что тема быстро развивается.
Главное, не воспринимать ИИ как магическую кнопку. Технология дает колоссальный доступ к информации, помогает в глубоких исследованиях, ускоряет подготовку материалов, может быть рабочим помощником и даже агентом под конкретные задачи. Но специалисту нужно уметь ставить задачи, проверять результат, критически осмыслять выводы, адаптировать их под контекст и не передавать машине ответственность за профессиональное суждение. В этом смысле критическое мышление становится ключевым навыком – чем больше возможностей дают инструменты, тем выше цена некритичного использования их результатов.
Сохранится ли роль наставника с развитием ИИ?
У ИИ-агента можно спросить почти все – от технической справки до структуры документа или объяснения новой темы. Я считаю, что роль наставника сохранится. Нейросети действительно помогают новичку быстрее ориентироваться в общей информации, объясняют термины, подсказывают подходы, структурируют знания. Но внутри каждой компании есть свои правила, контекст, неписаные договоренности, особенности взаимодействия, история решений, культура коммуникации. Это невозможно полноценно передать через внешнюю базу данных.
Наставник помогает человеку понять не только «как правильно по инструкции», но и «как это устроено именно у нас». Где нужно заранее согласовать позицию, к кому прийти за экспертизой, почему в этой команде принято действовать именно так, какие нюансы важны для клиента, где в процессе есть тонкое место. Такие знания передаются через живой опыт. Поэтому наставничество не конкурирует с ИИ, скорее, они могут усиливать друг друга: ИИ помогает быстрее освоить базовый слой информации, а наставник помогает встроиться в реальную профессиональную среду.
Стрессоустойчивость и работа с изменениями как часть профессии
Темы эмоционального интеллекта, экологичной коммуникации – это не просто личное развитие, но и напрямую влияют на рабочую эффективность. IT-рынок живет в постоянной турбулентности. Меняются технологии, клиентские запросы, экономическая ситуация, подходы к найму, внутренние процессы. На человека давит неопределенность, высокая скорость, необходимость быстро перестраиваться. В таком состоянии растет риск ошибок, падает вовлеченность, снижается продуктивность, а накопленный стресс может привести к выгоранию.
Поэтому специалистов и руководителей нужно учить замечать свое состояние, управлять стрессом, жить в изменениях, сохранять работоспособность в периоды неопределенности. Руководителям особенно важно уметь видеть признаки выгорания у сотрудников: если человек долго работает на пределе, усталость неизбежно начинает влиять на качество решений, коммуникацию и отношение к работе. Эмоциональная устойчивость – это не про «быть всегда спокойным». Это про способность не разрушаться под давлением, восстанавливаться, осознавать свои реакции, не переносить стресс на команду и принимать точные решения, даже когда вокруг много неопределенности.
Кроме того, один из рисков для опытного специалиста – замкнуться в собственной экспертизе. Чем дольше человек работает, тем больше у него оснований считать, что он уже многое видел, многое знает и его сложно удивить. Опыт действительно дает устойчивость, но иногда мешает увидеть новое. Для профессионального роста важно сохранять способность «обнуляться». Заходить в знакомую тему с установкой: возможно, здесь есть смысл, который я раньше не видел. Это не отказ от опыта, а умение временно отодвинуть привычные выводы и посмотреть на ситуацию свежим взглядом.
Я часто думаю об этом через аналогию с книгой. Один и тот же роман, прочитанный в школе и во взрослом возрасте, воспринимается совершенно по-разному. Текст тот же, автор тот же, но меняется сам читатель, его опыт, вопросы, зрелость. Так же и в профессии: иногда старая тема открывается иначе, потому что человек дорос до нового уровня понимания. Для IT-специалиста это особенно важно, технологии меняются быстро, подходы обновляются, привычные решения перестают быть единственно верными. Умение сделать шаг назад, переосмыслить свой опыт и заново увидеть задачу – это важная часть профессиональной гибкости.
Языки как доступ к другой технологической культуре
Английский по-прежнему остается важным языком профессиональной коммуникации в IT-отрасли. Но интерес к китайскому языку тоже понятен: Китай играет огромную роль в развитии высоких технологий, искусственного интеллекта, оборудования, инженерных решений.
Мое личное мнение: знание языков всегда расширяет возможности. Если страна занимает важное место в технологической повестке, то знание ее языка дает более глубокий доступ к обучению, переговорам, профессиональной среде, культуре принятия решений. Можно работать через перевод, но оригинальный язык помогает понять больше – не только слова, но и контекст. Для IT-специалиста это может стать дополнительным конкурентным преимуществом, особенно, если человек видит для себя интерес в международных проектах, обучении, технологическом обмене или работе с иностранными рынками.
Профессиональная зрелость – это тоже результат обучения
Обучение техническому стеку – это фундамент. Но поверх технологий выстраивается более сложная профессиональная конструкция: коммуникация, проектное мышление, клиентский сервис, управленческие навыки, ИИ-грамотность, критическое мышление, стрессоустойчивость, способность учиться и переучиваться. Компании, которые это понимают, получают более зрелые команды. Такие специалисты лучше слышат клиента, быстрее адаптируются, качественнее работают в проектах, спокойнее проходят через изменения и могут расти в разных траекториях: как глубокие эксперты, как проектные лидеры, как руководители команд, как специалисты на стыке технологий и бизнеса.
В IT-сфере важны сильные профессионалы, но сила специалиста измеряется не только тем, насколько хорошо он знает технологию, но и тем, насколько осознанно он умеет применять ее в реальной работе – с коллегами, процессами, клиентами, рисками и постоянными изменениями.
Учить конкретным технологиям или способности переучиваться?
Важны оба направления. Нельзя отказаться от обучения конкретным технологиям, потому что есть проекты, задачи, системы, решения, требующие глубокой специализированной экспертизы. Сертификации, узкие технические навыки, погружение в конкретную платформу или инструмент никуда не исчезают. Но стратегически ценится способность быстро переучиваться. Технологии развиваются стремительно, и специалисту важно уметь перестраиваться, осваивать новое, включать его в свою работу и не теряться каждый раз, когда привычная схема меняется.
Для кого-то гибкость естественна: такие люди легко пробуют новое и быстро переключаются. Кому-то, особенно людям основательным, привыкшим все планировать и продумывать, перестройка дается сложнее. Но это тоже навык, который можно развивать. Через обучение, практику, работу с изменениями, новые проекты и постепенное расширение профессионального поля.
Будущее за специалистами, которые умеют сочетать глубину и гибкость. Быть сильными в своей области, но не превращать эту область в закрытую комнату. Осваивать конкретные технологии, но понимать, что через год или два снова придется учиться.
Индивидуальный трек важнее универсального списка курсов
У нас в компании мы выстраиваем обучение через связку оценки, обратной связи и индивидуального плана развития. Для нас годовая оценка – не просто формальная процедура и не только рейтинг эффективности, главное, чтобы сотрудник получил качественную обратную связь от руководителя, увидел свои сильные стороны и зоны роста, а затем смог составить понятный и прицельный план развития. После этого обучение становится осознанным. Человек выбирает не случайный курс из общего каталога, а то, что действительно помогает ему в задачах. Внутри компании есть программы по личной эффективности, коммуникации, презентации, аргументации, типологиям личности, проектному управлению на базовом и продвинутом уровне. Для руководителей доступны модули по управленческому мастерству.
Такой подход важен еще и потому, что IT-специалисты разные, кто-то лучше учится в группе, через тренинг, обсуждение и практику, кому-то комфортнее начинать с самостоятельного дистанционного обучения, особенно, если человек привык глубоко погружаться в материал индивидуально. Поэтому важны и очные форматы, и онлайн-платформа, где можно закреплять навыки после тренинга или осваивать нужные темы в своем темпе.
Для обучения взрослых людей это принципиально: развитие работает лучше, когда человек понимает, зачем ему конкретный навык, как он связан с его задачами и где он сможет применить его уже завтра.
Также читайте:
В корректно ведущейся дискуссии можно подробно ответить на все воппосы, отблагодарив оппонента за труд! Поэтому простыня на простыню)))
Вся моя т.з. строится на 2х простых аксиомах (аксиома - утверждение не требующее доказательств):
Аксиома_1: "В задаче управления предприятиями выбор эффективной модели управления зависит от состояния бизнес-среды:
- если среда "стационарная", то можно и нужно использовать возможности прогнозирования и вести управления посредством планирования;
- если среда "турбулентная", т.е. планирование в ней не возможно/не эффективно, то нужно управлять методами реагирования."
Аксиома_2: "Решения по модели и методам управления для "стационарной" и "турбулентной" сред радикально отличны"
Для меня, это аксиомы, но наша дискуссия показывает, что это не является очевидной аксиомой для всех.
Если придерживаться этих 2х аксиом, то ответить на Ваши возражения/вопросы, очень просто (Вы сами можете легко смоделировать ответы в этой предлагаемой мною "системе координат")!
Давайте посмотрим на задачу эффективного управления через динамику бизнес-среды: была среда стационарной, стала турбулентной:
Предприятия управлялись методами планирования (и это было правильно, т.к. среда была стационарной), среда изменилась - стала турбулентной, а предприятия продолжают по инерции управлять своей деятельностью методами планирования.
Каких результатов следует ожидать в такой ситуации?
Ответ очевиден - плохих: наступает "хаос" - планы не выполняются, выполнение планов не приносит экономических дивидендов, приходится постоянно находится в режиме перепланирования, клиенты не довольны, затраты растут, а продажи падают.
В чем причины "хаоса"?
Не в том что методы управления на основе планирования плохи, сами по себе, не в том, что все сотрудники вдруг "поглупели", а процессы из эффективных вдруг превратились в неэффективные (все разладились)!?
Проблема в том, что предприятие для управления использует неприемлемую по эффективности модель, т.е. проблема в том, что предприятия применяют планирование там, где планирование не возможно!
Когда этот "хаос" прекратиться?
Когда предприятие сменит модель управления. и начнет управлять своей деятельностью в турбулентной среде методами реагирования!
Если это были сложные для принятия рассуждения, то приведу следующую, как мне кажется, простую аналогию:
Теперь в эту логику подключаем IT, как поставщика решений, поддерживающих модель управления:
Для стационарной среды IT-отрасль разработала адекватную условиям модель управления на основе планирования ERPlanning. Ситуация полной гармонии: Предприятие с помощью ERP эффективно управляется в стационарной среде и получает ожидаемую эффективность от такого управления.
Среда стала турбулентной. Предприятия начали активно перестраивать свои процессы на полу и методы под модель управления на основе реагирования (см. мою таблицу из публикации на ХАБРе). Что говорит в этой ситуации IT отрасль: "Продолжайте управляться методами на основе планирования (ERP - forever and best of the best!!!). Проблемы не в ERP (действительно же, методы управления на основе планирования реализованы отлично), а в том, что у вас на предприятиях много "хаоса". Исправьте свой "хаос" - и наши ERP решения будут отлично работать". Но, исходя из 2х аксиом, ERP++ не спасет, нужен только ERR.
В чем моя претензия:
1. Предприятия уже давно "стартовали" в новую реальность турбулентной среды и разработали уже множество решений (опять смотри мою таблицу на ХАБРе), многие из которых стали уже международными!!!! стандартами!!! (миллионы!!! промпредприятий в мире стараются им соответствовать).
2. А IT-отрасль этого агрессивно и упорно не замечает, и IT-решение класса ERReactioning (комплексное решение по управлению предприятиями и цепями поставок на основе реагирования) не разрабатывает!? И это не локальная российская особенность, а глобальная проблема (SAP так же с парадигмы планирования уходить не хочет). Т.е. вместо того, чтобы разработать ERR, IT отрасль пытается выплыть/отделаться (сами предложите синоним) решениями ERP++ (локальные фичи).
3. На Вашем примере, Никита: изучали ли Вы (сотрудники Вашей франчайзи-компании 1С) новые производственные решения из моей таблички с ХАБРа, чтобы, как минимум понять/разобраться, какие изменения нужно будет внести в текущие релизы? Если да, то КОГДА и ГДЕ/КАК? Это не праздный интерес: мне искренне интересен источник трансляции знаний из промышленности в IT отрасль (может проблема в этом трансляторе искажающем качество знаний, если такое обучение было!?)
Я смог аргументировать свои претензии к IT отрасли?
Конечно никакого by нет, т.к. IT-отрасль занимает сейчас позицию: "Нет Бога кроме Аллаха, а Магомет - пророк его на Земле!"="Нет никаких других подходов к управлению предприятием, кроме как на основе Планирования, а ERP - это ответ на все Ваши запросы по управлению предприятиями!"
Правильный же ответ звучит - см 2 аксиомы:
IT отрасль ставит знак равенства в уравнении "Управление предприятием = ERP (enterprise resource planning)" - ни мм места не оставив в названии для равноправно существующего альтернативного подхода к управлению предприятиями на основе РЕАГИРОВАНИЯ (т.е. ошибочно утверждая, что задача управления может быть решена, только методами планирования (все в соответствии с завещаниями господина Фрейда).
Правильный же ответ должен звучать следующим образом: если предприятию нужно построить корпоративную информационную систему управления предприятием/холдингом, то оно должно смотреть в сторону комплексных решений класса ER (enterprise resource), в котором есть два альтернативных решения (в зависимости от среды (турбулентная или стационарная) в которой работает предприятие):
Поэтому, чтобы остаться в 3х буквенных закрепившихся обозначениях, надо добавлять так критикуемый Вами "by"! И да, это мое предложение, которого нет в поисковиках.
Надеюсь эти обозначения разумны/логичны - совсем не крамольны? Вы против них? У Вас есть другие предложения?
Никита Андреев пишет:
Немного удивлен тем, что Вы воспринимаете ERP - как вывеску, под которой каждый может творить, что захочет (в стиле "мало ли что на воротах гаража написано"), т.е. отвергаете наличие "концепции ERP" ! Т.е. Вы отвергаете факт того, что существуют концептуальные ограничения, которые не позволяют любому решению для управления предприятияем именоваться ERP решением. Тогда как на самом деле, только решения, которые отвечают жесткому набору требований имеют право называться ERP решениями! Хотя называют же у нас Коньяком и Шампанским самые разные напитки!?)))
Вот как обстоят дела с концепцией ERP на самом деле (взял из вики, как приемлемое описание):
И текст от Алисы про то, кто этой КОНЦЕПТУАЛЬНОСТЬЮ заправляет:
Т.е. перевожу длинный текст в короткий ответ: ERP - это матрешка, внутри которой находится матрешка MPPII, внутри которой спряталась матрешка MRP. И все эти матрешки=КОНЦЕПЦИЯ управления на основе ПЛАНИРОВАНИЯ стандартизированы/зарегламентированы авторитетной компанией.
И обратите внимание на года (я специально 1960 и 1980) оставил в тексте, чтобы Вы увидели, что вся эта концепция была придумана во время господства "стационарной среды" для эффективной работы в ней. Никаких постановок задачи и решений про управление на основе реагирования в ней нет (ну не было такой потребности в эти годы, т.к. турбулентная среда еще не была "видна")
В Вашем вопросе (опять по Фрейду) во всей красе проявляется дефицит знаний о том, что происходит в Промышленности, так как искать Вам нужно распространение тех новаций (названия и краткое описание см все в той же таблички с ХАБРа) которые "на полу" с легкой руки Тойоты сейчас майнстрим (это комплекс решений по управлению на основе реагирования), и которые IT отрасль не может/не хочет поддержать соответствующей комплексной разработкой.
Если бы Вы искали, например, Бережливое производство, или APQ, то нашли бы подтверждения масштаба внедрения этих новаций в промышленности.
А зачем искать ERR (моя придумка с названием, которой я обозначил нужное промышленности комплексное решение, которое IT отрасль не хочет разрабатывать), естественно, Вы в сети под этой аббривиатурой ничего не найдете.
Во всем мире релизы ведоров по концепции ERP по-определению разные (никто в здравом уме и твердой памяти не будет утверждать, что ERP решение от 1С и SAP - это одно и тоже))) А вот концепция, на основе которой разрабатывают вендоры свои ERP решения - единая (см. текст выше) и это концепция управления предприятием на основе инструментария ПЛАНИРОВАНИЯ (никакого РЕАГИРОВАНИЯ нет ни в концепции ERP, ни в релизах вендоров, которые по этой концепции управления на основе ПЛАНИРОВАНИЯ создавали свои авторские продукты)
Ваш ответ подтверждает мой тезис, что Вы отвергаете мои Аксиомы, и что IT отрасль (в т.ч. и Вашем лице) стоит на позиции "задача управления предприятиями - это задача, которую нужно решать методами планирования!"
Вот я и задаюсь вопросом, как и чем эту "стену убеждения" можно разрушить!?
Очень может быть, что для того, чтобы подчеркнуть существенную разницу в подходах, я перегнул палку (правильно не сформулировал и не смог корректно донести мысль)(((
В чем сложность:
Все стандартизировано, только почему брак то получается, почему конвейеры останавливаются, почему одна и та же работа, занимает разное время (или по классике "почему в одну и ту же реку, нельзя войти дважды")!?
Плюс, есть проблема терминологическая (миграция терминов - плохое решение), т.к. под одним и тем же термином "стандартизированная работа", для разных моделей управления будут подразумеваться разные сущности. Поэтому, в т.ч. мысль моя звучит не корректно(((
Т.е. что я хочу сказать: стандартизированная работа - как точка/норматив типа "такая то работа по установке шпильки в коробку передач по такому то алгоритму заимет 347 секунд" - это невозможная на практике сущность, так как в реальности, в зависимости от кучи разных случайных условий и обстоятельств, время ее выполнения надо описывать не точкой/нормой, а интервалом (+- 10 секунд, но могут быть случаи, когда задержка будет, например и в 10 минут, или придется изменить алгоритм). Планировать же по интервалу - это такое экспоненциальное увеличение вариативности и сложности, что оно в модели Планирования не рассматривается "никаких интервалов - только точки, или, например, решения "по худшему варианту"". Поэтому то, что в системе планирования описано как сущность "стандартизированная работа" - это не более как "целевой медианное, целевой максимум". А в реагировании, по определению работа должна вестись от факта, но тогда стандартизированная работа - это какой-то микс неточно сформулированных правил допускающих разное время исполнения, возможность изменения алгоритма и т.п. + встроенный механизм реагирования на эту фактическую изменчивость. т.е. - это стандартизированное облако+ набор реакций, а не точка с одной реакцией - перепланировать. Следует ли облако называть стандартизированной работой!? Как нужно работать с облаком, в отличии от точки?
И другой аспект: а что нужно сделать с операцией установки шпильки в коробку передач, чтобы изменчивость этой операции уместить в приемлемый интервал? Как IT решение помогает такую работу поддержать? Как IT решение управляет этим процессом снижения вариативности результатов? Как получить эти интервалы вариативности? Как с ними работать? Т.е. возникает много управленческих задач, которых в инструментарии Планирования нет, а в Реагировании - это базово необходимые компетенции.
Как итог: согласен с тем, что про "стандартизированную работу" надо подумать,
Тут, ИМХО, существенная разница во времени которое подразумевается для подготовки к выполнению работ. При месячном планировании, все службы видят свою загрузку/работу на месяц вперед, т.е. могут запустить какие-то процессы подготовки заблаговременно. Т.е. это не вопрос, когда работник узнал, что ему делать (он может узнает это и за 30 секунд всего до начала очередного задания), вопрос в том как все прочие службы сработали и смогли в это самое время работнику необходимые материалы, инструменты, ресурс оборудования и т.п. собрать. Одно дело, мы готовимся к этому событию сильно заранее по плану, и совсем другое дело, когда у нас нет на это времени (должны реагировать "в прямом эфире"). Это две совершенно разные формы организации работ, которую в лоб не решить. Тут и появляется сигнальная система Канбан и вытягивающее планирование и математика балансирования мощностей и организационных решений, которой в ERP концептах нет.
Возможно, исходя из Вашего опыта работы в системах Планирования, Вам кажутся эти вопросы оригинальными/существенными/важными, но они никакого отношения к работе в системе Реагирования не имеют (они из разряда "ложками суп в невесомости же есть неудобно, значит ерунда эта ваша невесомость", только проблема в том, что ложек и привычного земного процесса приема пищи в невесомости нет). Т.е. эти вопросы лишь показывают, что Вы не понимаете, какой должна быть организация работ и система управления основанная на реагировании, и Ваши предположения о том что думает, что делает, что ждет, что работнику надо - все большая несуразица какая-то.
Т.е. Вам нужно повышать знания о том какие решения нужны/применяются для вытягивающего планирования
А это свидетельство Ваших слабых представлений об изменчивости, которая влияет на результаты техпроцессов. И вам надо бы, например, познакомиться с таким руководтвом, как APQP
А дальше Вас опять "понесло" и на этот неуместный стеб и пургу я реагировать не буду