Обучение 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
А дальше Вас опять "понесло" и на этот неуместный стеб и пургу я реагировать не буду
Если суммировать ваши аксиомы, вам нужно ИТ-решение, в котором предусмотрено нахождение объекта (предприятия) в суперпозиции, т.е. сразу в нескольких состояниях: в "динамическом изменении" в краткосрочном периоде и в рамках бюджета в среднесрочном периоде (с возможностью корректировки последнего в зависимости от изменений в краткосрочном).
Так для этого предусмотрено "скользящее планирование", которое технически реализовано.
Я в курсе что такое аксиома, но в этом-то и проблема, ваши странные тезисы практически все крайне спорны и ТРЕБУЮТ доказательств.
У слова "стационарный" (например, если мы говорим про временной ряд спроса, что наиболее близко у предмету), антоним - "не стационарный"
У слова "турбулентный" (например "поток") антоним "ламинарный", то есть все равно движущийся.
А вот это "турбулентная экономическая среда в экономике" появляется там где гуманитарии хотят играть в технарей и математиков:
"В работах Э. Тоффлера не дается определение
самому термину «турбулентность», однако описываются причины ее возникновения в глобальном и
цивилизационном поле, проявляющиеся в виде смены «трех волн», оказывающих шоковое воздействие
на социально-экономические системы"...
"На микроуровне турбулентность определяется
как свойство непосредственной среды организации
(организационной среды), отличающееся быстрыми,
непредсказуемыми и масштабными изменениями"
...
"Общей характеристикой для всех
уровней является непредсказуемость изменений и взаимосвязанность элементов
системы, однако на макроуровне акцент
смещается на системные разрывы и бифуркации, на мезоуровне – на пространственные и структурные диспропорции,
а на микроуровне – на операционную неопределенность и конкурентное давление."
(Сообщение отредактировано модератором)
Вот потому у вас (называющего себя математиком), и формул в статьях нет - вас укусили гуманитарии и вы уже, как в вампира, обратились в гуманитария.
(Сообщение отредактировано модератором) а с каких это пор у нас урезание костов в рамках антикризисного управления стало вдруг "радикально отличным методом управления"? )
(Сообщение отредактировано модератором)
Да подбитый раненный летчик со всем отказавшими двигателям и то ПЛАНИРУЕТ аварийную посадку, прикидывая свой курс, куда он сядет, желательно на поле, а не в лес.
Иронично, что "планирование" имеет здесь сразу 2 значения - то что предполагается им, как его будущее, и режим полета самолета по инерции за счет накопленной высоты, обменивая ее на скорость, необходимую для сохранения подъемной силы.
Для предприятия это тоже актуально - но только не у вас, у вас заело пластинку, что "планирование" = "плохо".
А позвольте узнать, есть какие-то формальные критерии отсечки, чтоб понять - вот вчера "планирование" = "правильно", а сегодня "планирование" = "плохо" и уже надо выбросить ERP за 100млн.р. на помойку и делать с нуля ERR? )
Или каждый месяц надо вас звать, чтобы вы волшебным осцилографом замеряли уровень знаменитой "турбулентности", что бы она черт возьми не значила? )
Это не "результаты планирования", а "результаты неправильного планирования", плюс общая культура управления предприятием.
Вот эта "аксиома" точно требует доказательств.
А именно, пока вы не
1) разработаете внятную альтернативную методику (речь не про лозунги, которые вы опубликовали на хабре)
2) внедрите ее и она покажет эффективность,
тогда и только тогда вас начнут воспринимать всерьез, на слово никто никому не верит, тем более "консультантам" ).
Не существует "аксиом" одного человека (Сообщение отредактировано модератором), обязательных к "вере" для всех. это то что признало, допустим, сообщество математиков, физиков, а не то что вы думаете.
Например, аэропорт Хитроу внедрял SAP с международными!!!! стандартами!!! - результат на табло, неделя простоя ).
потрясающе бессмысленное определение "агрессивно не замечает"
я вам рассказывал 5 раз уже, как IT отрасль работает (и что там цена входа в бизнес в эту отрасль, с вашим ERR, - купить компьютер и скачать книги про SQL и Java), вам плевать и вы 5 раз пишите про международный заговор IT отрасли )
в промежутках жалуетесь, что ваши жалобы на сайт Спортлото никто не слышит ).
(Сообщение отредактировано модератором) (с)
и в 5й раз пишу - я 8 лет 1С не занимаюсь, потому что работал в банке Исполнительным директором и занимался ИИ. )
ну вы же не читаете. )
как изучали?
книги и интернет.
а вы как изучали? в Японию ездили?
(Сообщение отредактировано модератором)
там ясно видно, что рецепты помощи предприятию в "турбулентной среде" (не имеющей определения) это консалтинговое плацебо и научным методом, доказательным подходом там и не пахнет.
ну, приходит пациент к гомеопату, говорит у меня на спине гноящаяся рана и температура шпарит, а врач вместо оперативного вмешательства и антибиотиков (а он такое и не умеет - у него диплома нет) рассказывает "ваше состояние стало турбулентным" дает визитку магазина с БАДами и вдобавок начинает рекламировать веганство и пилатес.
(Сообщение отредактировано модератором)
Нет конечно.
(Сообщение отредактировано модератором)
Вот просто для общего развития, посмотрите комедийный сериал "Кремниевая долнина", как ИТ отрасль, гаражные стартапы из пары человек, за неделю клепает прототипы с которыми далее идет к инвесторам и получает миллионы долларов на развитие.
Вы могли бы точно так же, взлететь и обогатиться. )
Но это в том случае, если идеи чего-то стоят.
А если идеи - набор сомнительных лозунгов без единого алгоритма и без единой формулы, как у вас, вам не доверят даже руководство группой программистов в пару человек на вашем заводе.
Могли бы студентам поручить создать прототип в рамках практических работ, но все мы знаем качество образования ВШЭ, эти вам напрограммируют. )
Исходя из ваших голосов в голове, которые вы называете "аксиомами".
Но, разговора ради, согласимся, что "предприятия начали активно перестраивать свои процессы".
И еще ваша цитата "...(миллионы!!! промпредприятий в мире стараются им соответствовать)."
То есть все знают что там за процессы ERR, и стараются соответствовать, перестраивают, да, миллионы предприятий?
Ну так если предприятия начали перестаивать, их ИТ отделы получили задания модифицировать КИС (инсорсом или аутсорсом, неважно), либо создавать новые КИС, которые в итоге выйдут на рынок (ну тупо наглый подрядчик скопирует с предприятия и выпустит под своим брэндом), растиражируются и уделают ERP как Бог черепаху? Ведь так же по логике?
Что там, у условного Газпрома, Роснефти, Трансмаш, ОМК, ОСК и т.п. нету денег сделать КИС с нуля, нанять 10 подрядчиков (в т.ч. они и великих "вендоров" могут тупо купить на год и заставить работать по своим ТЗ) или взять в штат 10000 разработчиков, аналитиков, методологов на сдачу еще вас в штат нанять на фуллтайм? )
Но в вашей (Сообщение отредактировано модератором) картине мира это может произойти только после благословения "вендора" на смену названия на гораздо более дурацкое и нелогичное, пихай туда предлог by или нет ).
(Сообщение отредактировано модератором)
Вы вот почитайте комент выше уважаемой Эльвиры - вам черным по белому пишут что ОБА ПОДХОДА В РЕШЕНИЯХ есть!
Почему она так пишет?
Потому что работает в системе и овладела функционалом, а вы дальше названия ERP не продвинулись в изучении, отдали на откуп студентам, они вас накормили галиматьей, что на рынке ничего нет. )
Ну так вы вставляете произвольно (и обычно неграмотно) новые слова в аббривеатуры, и тут же утверждаете, что "Enterprise resource by reactioning, которое давно уже реализовано первопроходцем Тойотой и активно распространяется сейчас по производственному миру как «обязательно к применению»".
Вопрос тот же самый, что и раньше - зачем вы лжете? )
"Enterprise resource by reactioning" никем нигде не распространяется, оно появилось только что в вашей голове в результате плохого владения английским.
я вам писал, что когда рано или поздно вы полезете (в связи со своей "великой образованностью") на вики, вы найдете там максимально устаревшую информацию "от времен Очаковских" - но вы ж не читаете.
повторяю для особо одаренных в 5 раз:
НЕ СУЩЕСТВУЕТ НИКАКОГО ВЫСШЕГО ОРГАНА ПО СООТВЕТСТВИЮ НАЗВАНИЮ ERP!
я на днях опубликую проект и там будут эти буквы, кто-то подаст на меня в суд?
и вас не смутил на этой странице Википедии такой пассаж ( (Сообщение отредактировано модератором))?
"Также иногда в состав финансовых модулей ERP-систем включены финансовое планирование и управление ключевыми показателями эффективности, но основные разработчики поставляют для этих функций отдельные специализированные программные продукты."
А еще, например, туда же в ERP запихивают CRM, и все что угодно можно завтра воткнуть, хоть черта лысого, в зависимости от политики компании которая продукт выпускает.
Это компания решает, что будет в том или ином ее продукте - и по результатам про нее будут редактировать эту статью на Википедии!
А в вашем больном воображении, наоборот, компания выпустила что-то, и пишет в энциклопедию (википедия это электронная энкциклопедия, если что) письмо - можно, мол, мы назовемся ERP?
А оттуда отвечают, нет вы слишком много туда напихали, называйтесь ERPLGBT++.
А если бы вы работали в разных (начиная с ранних) версиях, например 1C:ERP, вы бы увидели что они меняются, переделываются, дорабатываются с бешеной скоростью, у вас таких мыслей о "концепции ERP", которой производители пытаются соответствовать, и не возникло бы - они работают с ПОТРЕБНОСТЯМИ ПРОИЗВОДСТВА, думая о том что там написано на вики в последнюю очередь.
(Сообщение отредактировано модератором)
(Сообщение отредактировано модератором)
см. сообщение Эльвиры.
впрочем, вам из погреба виднее.
Я сейчас не совсем в IT, занимаюсь строительством (по сути то же производство, но сложнее), управляю бригадой.
И мне знаете, как-то цикл Деминга PDCA (Plan Do Check Act) ближе каких-то бредней Владимира Михейкина, что слово Plan надо отовсюду повычеркивать.
Как-то Деминг, знаете, повесомее будет, чем ваши прости Госсподи, аксиомы (можно все-таки с маленькой буквы писать?)
потому что руководители плохо выполняют свою работу, плохо анализируют ошибки, верят на слово бракоделам и разгильдяям и проявляют управленческую импотенцию.
а вы как консультант не особо помогаете, валя все на ERP систему.
это подход Ходжи Насредина с обучением ишака говорить - либо ишак либо падишах сдохнут, пока поменяется ERP система.
и да, очень удобно утверждать, что ее надо именно новую, потому что предложения по доработкам (с нормальной постановкой) реализуют за неделю, и валить будет уже не на кого.
вопрос лишь в том, добросовестно ли вы заблуждаетесь, или цинично лжете своему руководству и нам тут заодно ).
(Сообщение отредактировано модератором)
они УЖЕ НА МЕСТЕ.
в 1C:ERP есть "тянуший" фукнционал работы с цеховыми кладовыми, он пошел и взял, неснижаемый остаток возмещают - DBR Голдратта в чистом виде.
Да повторю, никто не обязан свои КИС дорабатывать в соответствии с "концептами", потребность появилась - ее взяли и закодили прямо на заводе местным программистом без "вендора" (и даже, о ужас, в курс никого не поставили - ни вендора, ни википедию).
Вендор, может, через год об этом узнает, когда ему принесут положительный отзыв о доработке типового функционала, и он пошлет методистов смотреть что там допилили (если это мега-важный клиент с 10000+ арм).
Ну, вам все об стенку горох.
В вашей картине мира, вы прочитали в книге про "математику балансирования", написали об этом на сайте Спортлото, вас там разумеется заметил гендир "Вендора", послал к вам на поклон своего зама с толстым конвертом денег (как в книге у Голдтратта описано), вы снизошли до них и обучили, и работа по разработке началась с этого момента ).
А в реальном мире все намного проще. )
Я утрированно показываю, что ваши тезисы высокого уровня "какая-то система сигналов", "делать то что важно", разобьются о вопросы рядого рабочего в первый же день.
У вас в голове нет ПОЛНОЙ картины как вы будете управлять, вы промычали какие-то лозунги и назвали это РЕАГИРОВАНИЕ, но лучше от этого не станет на производстве.
Ознакомился.
Запрограммировать в прототип можно за день эту схему процессов.
Уверен что кто-то и сделал это.
Поможет ли она кому-то? Может быть.
Но вы-то тут причем с вашей ERR? )
Не правильно "суммируете")))
В среде где планы и нормативы "не работают", планирование деятельности по нормативам - губительное по эффективности занятие. Зачем, например, планировать выпуск 10 белых изделий, если по итогу купят только одно?
Мне кажется, что причина Вашего оппонирования (выражающаяся в попытках показать что планирование - универсальное решение), кроется в том, что либо Вы не понимаете разницы между планированием и реагированием, либо плохо представляете себе среду, в которой планирование - плохое решение.
Обсуждаемый пример с рестораном - это же очевидный примертого, что планирование для управления деятельностью по обслуживанию посетителей неприменимо, только реагирование. Так в ресторане нет аналога центра планирования (ПДО) который разрабатывал бы согласованные планы для официантов, поваров, закупщиков, уборщиков. А все они работают по принципу - пришел сигнал на выполнение какой-то работы - я его обрабатываю, нет сигнала - бездействую. Т.е. официант не придет за блюдом в 10-05 как по какому то плану/нормативу, он придет тогда, когда получит сигнал от повара, что блюдо готово.
Еще самый простой пример, управление цепью людей которые передают кирпичи из-рук в руки: нет же подетальных пооперационных планов для каждого участника в стиле в 10-00 - получить первый кирпич, в 10-05 передать 1ый кирпич участнику №2 и тд. Если кто-то устал и стал медленней работать, остановился на передышку или вообще вышел из цепочки, цепочка сама на все правильно отреагирует и никакие планы ей для этого не нужны (они только вредны).
Поэтому любые варианты планирования по нормативам, в среде где по определению они не будут работать (а я именно так и определил зону турбулентной среды) - это неприемлемое по эффективности решение по-определению
Если были бы в курсе, то не требовали бы доказательств аксиом)))
Если Вы не согласны с тем, что существует такое состояние бизнес-среды, в котором планы и нормативы не работают, несмотря на мои примеры таких сред, то как я Вам это могу доказать!? Вы либо эту аксиому принимаете, и тогда, мы вместе рассматриваем решения, которые будут эффективно работать в такой среде, либо вы отрицаете существование такой среды (такой аксиомы)!?
Так же и со второй аксиомой про существенное различие эффективных решений для этих сред: если планы и нормативы не работаютв турбулентной среде, то искомые решения будут "не планы" и "не нормативы". Опять же, либо Вы с этим согласны, либо нет! Какие доказательства и формулы этим утверждениям-аксиомам Вы постоянно требуете!?)))
Если Вы не принимаете аксиоматику, не изучаете прикладные аспекты, то естественно, что для Вас эта "новая система координат" не понятная)))
А для меня, например, все Ваши "возражения" с т.з. введенной аксиоматики - это набор каких то неприменимых требований и ситуаций для рассматриваемой системе координат (если бы Вы в ней разобрались - такого бы не написали)
около 3 млн. компаний по миру сертифицированы по ISO 9001 и пытаются перейти на процессное управление, вместо которого вынуждены пользоваться IT решениями основанными на функциональном управлении.
Как минимум, вся автомобильная отрасль (а по ее стопам идут многие другие отрасли) перешла/переходит:
а у отечественных вендоров (прежде всего 1С) нет ничего эти преобразования поддерживающего (в доступе есть только противоположные по смыслу/идеологии IT-решения)
Про то, сколько компаний перестраивают свои производственные системы в соответствии с концепцией Бережливое производство, Алиса дает оценку - около 70% промпредприятий по миру
Ваши же вопросы-сомнения демонстрируют полное непонимание и невовлеченность в происходящие преобразования (Вы не в контексте от слова СОВСЕМ). Но это не мешает Вам навешивать с "высоты" своего незнания оценки "выдумок и глупостей" на все эти новации
"Все в промышленности знают" прикладные решения, которые они реализуют "на полу". Поддерживающего комплексного IT решения для этих преобразований нету (ERP - не тянет (оно противоположное по смыслу), нужно другое IT решение, которого нет и которое я назвал ERR). Хотите его обсудить, оспорить - начните с изучения исходных прикладных внедряемых промышленностью инноваций.
Т.е. никогда в жизни не изучали прикладные решения (не говоря о том, чтобы осуществлять мониторинг новаций в промышленности в области решений по организации производства и системе управления)!?
Получается, что прикладные новации, внедрение которых сейчас происходит в промышленности, Вы никогда не изучали/не знаете/не понимаете от слова совсем, но успешно сертифицированы!?, воспроизводите какую-то нелепицу про эти новации, и при этом утверждаете, что ERP все "это неизвестное Вам" успешно реализует! Вот это точно, как минимум, странно!?
Вы предлагаете кому то из этих корпораций сначала стать аналогом
Американского общества по управлению производством и запасами (APICS, American Production and Inventory Control Society) и разработать международные стандарты-аналоги MRP-MRPII-ERP (только основанные не на планировании, а реагировании). Потом стать вендором a-la SAP, чтобы создать универсальную (для любых поставщиков свооей цепи поставок) комплексную IT-платформу управления предприятиями/цепями поставок на основе реагирования. А потом организовать внедрение/поддержку этой IT платформы у себя в корпорации и у всех своих поставщиков/субпоставщиков по миру, не входящих в состав корпорации. Т.е. Вы предлагаете, например, ОСК, сменить род деятельности, и вместо строительства кораблей, занятся научными исследованиями в области управления, международной стандартизацией и деятельностью по разработке/сопровождению IT платформы и внедрению и поддержке решений на ее основе!? И чего это ОСК этим не займется и не выделит на это денег!? У них же есть штатные программисты!?)))
Если бы Вы понимали смыслы и масштабность задачи, Вы бы подобные предложения не озвучивали бы)))
Так я и говорю о тотальной безответственности и невежестве, которые распространены в IT отрасли!? Любой продукт (любую отсебятину) Вы назовете ERP, и, почему-то, абсолютно уверены в его полезности/безопасности для предприятия!? При этом, как выяснилось, Вы даже не знаете положений и структуры концепции ERP!? А виновато в плохих результатах будет предприятие, потому что оно плохо реализовало гениальный замысел Вашей разработки?! Просто удивительная ситуация(((
(Сообщение отредактировано модератором)
Уважаемые участники Сообщества,
Настоятельно прошу не переходить на личности, грубые сравненияи высказывания.
В следующий раз будет бан всех, кто позволил себе подобную форму общения (даже в ответ).
с 1 тезисом ок.
1 уровень
Постараюсь)))
Определения для бизнес-среды производственных предприятий (т.к. анализируем 2 ключевые характеристики (1) спрос на продукцию и (2) возможности производства)
«Стационарной» предлагается называть такую среду, в которой на горизонте планирования:
т.е. это предсказуемая среда, в которой управление методами планирования результативно и эффективно (можно и нужно воспользоваться возможностью точных предсказаний).
«Турбулентной» предлагается называть среду, с противоположными свойствами «Стационарной» среды, т.е. это состояния когда:
т.е. это непредсказуемая (высоко изменчивая, случайная) среда, в которой управление методами планирования неприемлемо, управление нужно строить от наблюдаемых фактов, т.е. методами реагирования.
Дополнительные признаки (уже не так точно):
Стационарной среды: СПРОС > ПРЕДЛОЖЕНИЯ, малорисковая конкурентная среда, сдерживаемая производителем номенклатурная изменчивость продукции, цену назначает производитель, вся выпущенная продукция будет продана с прибылью, критерий успешности/метрики - объемы производства (производительность типовой продукции)
Турбулентной среды: СПРОС < ПРЕДЛОЖЕНИЯ, высокорисковая конкурентная среда, номенклатурная изменчивость задается потребителями (неограниченно растущая), цену определяет потребитель/рынок, только точно вовремя выпущенная персонализированная продукция будет продана с прибылью, критерий успешности/метрики - время производства (персонализация точно вовремя), степень удовлетворенности потребителя
без контекста
вы даете понятие
слона надо есть по кусрчкам, а горячее не надо сравнивать с зеленым или громким
Так проблема исключительно в контексте и заключается: я в нем вижу систему связей, а Вы - зеленое с громким!?
Поэтому (если это, конечно, интересно сторонам), для установления точки ускользания нужно конкретизировать расхождения, где и что мы не одинаково трактуем?
А так то, конечно: небо - голубое, вода - мокрая и констатировать прописные истины можно до бесконечности)))