Обучение IT-специалистов начинается с технологий: языки программирования, архитектура, инфраструктура, информационная безопасность, сертификации, новые платформы, новые инструменты. Это логично, но профессионального развития исключительно в своей предметной области недостаточно. В большинстве IT-компаний разработчик не только пишет код. Он также инженер, архитектор, аналитик, специалист технической поддержки, руководитель проекта, менеджер технической команды, эксперт, который участвует во встречах с клиентом, помогает сформулировать задачу, объясняет сложные решения простым языком и отвечает за то, чтобы технология действительно заработала в бизнес-процессе.
Поговорим о том, какие навыки стоит развивать профессионалам, когда IT-рынок меняется.
Эффективная коммуникация как часть инженерной культуры
Кажется, что для технического эксперта главное – глубина знаний, способность быстро найти решение, настроить систему, разобраться в архитектуре. Это действительно основа профессии, но любая технология внедряется людьми и для людей. Чтобы проект состоялся, нужно понять запрос бизнеса, снять ожидания клиента, договориться с коллегами, аргументировать техническое решение, объяснить риски, пройти через конфликтную ситуацию и при этом не разрушить отношения. В этом смысле коммуникация перестает быть «приятным дополнением» к профессии, и становится рабочим инструментом.
Особенно это заметно в клиентских проектах. IT-специалист может прекрасно разбираться в решении, но если он не умеет задавать уточняющие вопросы, слышать разные типы собеседников, переводить техническую логику на язык бизнес-результата, проект начинает буксовать. Где-то возникает недопонимание, где-то клиент ждет одного, команда делает другое, где-то конфликт можно было снять на раннем этапе, но его просто не распознали.
Поэтому в развитии IT-команд важно учить не абстрактному «умению общаться», а вполне прикладным вещам: как выстраивать диалог, как работать с возражениями, как презентовать решение, как вести сложный разговор, как понимать разные типы личности и подбирать формат взаимодействия под конкретного человека. Для технического специалиста это такой же навык, как и умение работать с системой.
Проектное мышление: видеть путь от задачи до результата
Для инженеров, архитекторов, аналитиков и технических руководителей это особенно значимо, потому что большая часть их деятельности строится вокруг проектов разной сложности и длительности. Проектное мышление помогает специалисту видеть не только свою часть работы, но и весь маршрут: что должно быть на входе, какие этапы предстоит пройти, где возможны риски, кто влияет на результат, какие сроки реалистичны, какие договоренности нужно зафиксировать заранее. Это сильно повышает качество работы, потому что специалист начинает мыслить не отдельной задачей, а конечным эффектом.
В IT-сфере это критично. Один проект может быть коротким и понятным, другой – длинным, многоуровневым, с большим количеством участников и зависимостей. И если технический эксперт умеет управлять только своим участком, но не видит общей логики, команде сложнее удерживать сроки, качество и ожидания заказчика.
Здесь обучение должно быть привязано к роли, специалист технической поддержки больше взаимодействует с клиентом напрямую, поэтому для него особенно важны коммуникация, клиентский сервис, стрессоустойчивость, способность быстро разбираться в запросе. Инженер или архитектор, который участвует в проектировании инфраструктуры, должен дополнительно понимать этапность проекта, зависимость решений, логику согласований, управление рисками. Руководителю технической команды нужен следующий уровень – управление людьми.
Когда специалист становится руководителем, уровень сложности резко меняется. Раньше он отвечал в первую очередь за себя и свои задачи, теперь нужно управлять людьми, мотивацией, развитием, конфликтами, ожиданиями и командной динамикой. Это отдельная профессия внутри профессии, техническая глубина помогает руководителю быть авторитетным, но не заменяет управленческие навыки. Нужно понимать цикл менеджмента, основы ситуационного лидерства, разные стили управления и как они связаны с уровнем зрелости сотрудников. Одному человеку нужна подробная постановка задачи и сопровождение, другому больше автономии, третьему – помощь в мотивации, четвертому – честная обратная связь.
Для IT-команд это особенно важно, потому что специалисты часто ценят профессиональную свободу, уважение к экспертизе и честный диалог. Управлять такой командой директивно и одинаково для всех невозможно, руководитель должен видеть, кто на каком этапе находится, кому нужно дать больше поддержки, кому – больше ответственности, а где важно вовремя заметить выгорание или потерю вовлеченности. Поэтому управленческое обучение для IT-специалистов должно включать не только планирование и контроль, но и мотивацию, принятие решений, управленческое влияние, построение эффективной команды, развитие сотрудников и работу с обратной связью.
Обучение работе с искусственным интеллектом
Здесь важно разделять несколько направлений:
- Базовая ИИ-грамотность для сотрудников. Людям нужно понимать, что это за инструменты, как их можно применять в ежедневной работе, какие задачи они помогают ускорять, где дают хороший эффект, а где требуют осторожности. Для этого проводятся обучающие марафоны и дистанционные курсы, где сотрудники могут разобраться с темой на практическом уровне.
- ИИ как решение для бизнеса. Здесь обучение требуется тем, кто продает, проектирует, внедряет и сопровождает такие решения: аккаунт-менеджерам, инженерам, архитекторам, проектным командам. Им важно понимать, какие бизнес-задачи решает ИИ, как технология встраивается в процессы клиента, какую ценность создает, какие ограничения имеет и как объяснять это заказчику.
- Использование ИИ внутри собственных процессов. Это уже про зрелость организации: где ИИ может помочь в оценке, обучении, создании курсов, анализе данных, подготовке материалов, оптимизации повторяющихся операций. Здесь компании во многом идут через исследование, тестирование и постепенное внедрение, потому что тема быстро развивается.
Главное, не воспринимать ИИ как магическую кнопку. Технология дает колоссальный доступ к информации, помогает в глубоких исследованиях, ускоряет подготовку материалов, может быть рабочим помощником и даже агентом под конкретные задачи. Но специалисту нужно уметь ставить задачи, проверять результат, критически осмыслять выводы, адаптировать их под контекст и не передавать машине ответственность за профессиональное суждение. В этом смысле критическое мышление становится ключевым навыком – чем больше возможностей дают инструменты, тем выше цена некритичного использования их результатов.
Сохранится ли роль наставника с развитием ИИ?
У ИИ-агента можно спросить почти все – от технической справки до структуры документа или объяснения новой темы. Я считаю, что роль наставника сохранится. Нейросети действительно помогают новичку быстрее ориентироваться в общей информации, объясняют термины, подсказывают подходы, структурируют знания. Но внутри каждой компании есть свои правила, контекст, неписаные договоренности, особенности взаимодействия, история решений, культура коммуникации. Это невозможно полноценно передать через внешнюю базу данных.
Наставник помогает человеку понять не только «как правильно по инструкции», но и «как это устроено именно у нас». Где нужно заранее согласовать позицию, к кому прийти за экспертизой, почему в этой команде принято действовать именно так, какие нюансы важны для клиента, где в процессе есть тонкое место. Такие знания передаются через живой опыт. Поэтому наставничество не конкурирует с ИИ, скорее, они могут усиливать друг друга: ИИ помогает быстрее освоить базовый слой информации, а наставник помогает встроиться в реальную профессиональную среду.
Стрессоустойчивость и работа с изменениями как часть профессии
Темы эмоционального интеллекта, экологичной коммуникации – это не просто личное развитие, но и напрямую влияют на рабочую эффективность. IT-рынок живет в постоянной турбулентности. Меняются технологии, клиентские запросы, экономическая ситуация, подходы к найму, внутренние процессы. На человека давит неопределенность, высокая скорость, необходимость быстро перестраиваться. В таком состоянии растет риск ошибок, падает вовлеченность, снижается продуктивность, а накопленный стресс может привести к выгоранию.
Поэтому специалистов и руководителей нужно учить замечать свое состояние, управлять стрессом, жить в изменениях, сохранять работоспособность в периоды неопределенности. Руководителям особенно важно уметь видеть признаки выгорания у сотрудников: если человек долго работает на пределе, усталость неизбежно начинает влиять на качество решений, коммуникацию и отношение к работе. Эмоциональная устойчивость – это не про «быть всегда спокойным». Это про способность не разрушаться под давлением, восстанавливаться, осознавать свои реакции, не переносить стресс на команду и принимать точные решения, даже когда вокруг много неопределенности.
Кроме того, один из рисков для опытного специалиста – замкнуться в собственной экспертизе. Чем дольше человек работает, тем больше у него оснований считать, что он уже многое видел, многое знает и его сложно удивить. Опыт действительно дает устойчивость, но иногда мешает увидеть новое. Для профессионального роста важно сохранять способность «обнуляться». Заходить в знакомую тему с установкой: возможно, здесь есть смысл, который я раньше не видел. Это не отказ от опыта, а умение временно отодвинуть привычные выводы и посмотреть на ситуацию свежим взглядом.
Я часто думаю об этом через аналогию с книгой. Один и тот же роман, прочитанный в школе и во взрослом возрасте, воспринимается совершенно по-разному. Текст тот же, автор тот же, но меняется сам читатель, его опыт, вопросы, зрелость. Так же и в профессии: иногда старая тема открывается иначе, потому что человек дорос до нового уровня понимания. Для IT-специалиста это особенно важно, технологии меняются быстро, подходы обновляются, привычные решения перестают быть единственно верными. Умение сделать шаг назад, переосмыслить свой опыт и заново увидеть задачу – это важная часть профессиональной гибкости.
Языки как доступ к другой технологической культуре
Английский по-прежнему остается важным языком профессиональной коммуникации в IT-отрасли. Но интерес к китайскому языку тоже понятен: Китай играет огромную роль в развитии высоких технологий, искусственного интеллекта, оборудования, инженерных решений.
Мое личное мнение: знание языков всегда расширяет возможности. Если страна занимает важное место в технологической повестке, то знание ее языка дает более глубокий доступ к обучению, переговорам, профессиональной среде, культуре принятия решений. Можно работать через перевод, но оригинальный язык помогает понять больше – не только слова, но и контекст. Для IT-специалиста это может стать дополнительным конкурентным преимуществом, особенно, если человек видит для себя интерес в международных проектах, обучении, технологическом обмене или работе с иностранными рынками.
Профессиональная зрелость – это тоже результат обучения
Обучение техническому стеку – это фундамент. Но поверх технологий выстраивается более сложная профессиональная конструкция: коммуникация, проектное мышление, клиентский сервис, управленческие навыки, ИИ-грамотность, критическое мышление, стрессоустойчивость, способность учиться и переучиваться. Компании, которые это понимают, получают более зрелые команды. Такие специалисты лучше слышат клиента, быстрее адаптируются, качественнее работают в проектах, спокойнее проходят через изменения и могут расти в разных траекториях: как глубокие эксперты, как проектные лидеры, как руководители команд, как специалисты на стыке технологий и бизнеса.
В IT-сфере важны сильные профессионалы, но сила специалиста измеряется не только тем, насколько хорошо он знает технологию, но и тем, насколько осознанно он умеет применять ее в реальной работе – с коллегами, процессами, клиентами, рисками и постоянными изменениями.
Учить конкретным технологиям или способности переучиваться?
Важны оба направления. Нельзя отказаться от обучения конкретным технологиям, потому что есть проекты, задачи, системы, решения, требующие глубокой специализированной экспертизы. Сертификации, узкие технические навыки, погружение в конкретную платформу или инструмент никуда не исчезают. Но стратегически ценится способность быстро переучиваться. Технологии развиваются стремительно, и специалисту важно уметь перестраиваться, осваивать новое, включать его в свою работу и не теряться каждый раз, когда привычная схема меняется.
Для кого-то гибкость естественна: такие люди легко пробуют новое и быстро переключаются. Кому-то, особенно людям основательным, привыкшим все планировать и продумывать, перестройка дается сложнее. Но это тоже навык, который можно развивать. Через обучение, практику, работу с изменениями, новые проекты и постепенное расширение профессионального поля.
Будущее за специалистами, которые умеют сочетать глубину и гибкость. Быть сильными в своей области, но не превращать эту область в закрытую комнату. Осваивать конкретные технологии, но понимать, что через год или два снова придется учиться.
Индивидуальный трек важнее универсального списка курсов
У нас в компании мы выстраиваем обучение через связку оценки, обратной связи и индивидуального плана развития. Для нас годовая оценка – не просто формальная процедура и не только рейтинг эффективности, главное, чтобы сотрудник получил качественную обратную связь от руководителя, увидел свои сильные стороны и зоны роста, а затем смог составить понятный и прицельный план развития. После этого обучение становится осознанным. Человек выбирает не случайный курс из общего каталога, а то, что действительно помогает ему в задачах. Внутри компании есть программы по личной эффективности, коммуникации, презентации, аргументации, типологиям личности, проектному управлению на базовом и продвинутом уровне. Для руководителей доступны модули по управленческому мастерству.
Такой подход важен еще и потому, что IT-специалисты разные, кто-то лучше учится в группе, через тренинг, обсуждение и практику, кому-то комфортнее начинать с самостоятельного дистанционного обучения, особенно, если человек привык глубоко погружаться в материал индивидуально. Поэтому важны и очные форматы, и онлайн-платформа, где можно закреплять навыки после тренинга или осваивать нужные темы в своем темпе.
Для обучения взрослых людей это принципиально: развитие работает лучше, когда человек понимает, зачем ему конкретный навык, как он связан с его задачами и где он сможет применить его уже завтра.
Также читайте:
Вы всех Заказчиков сертифицировать по ERP хотите!? Т.е. не Вы их, а они Вас понимать должны!? Сильно))))
Попытался найти критику ERP не в моем исполнении (на меня у Вас устойчивое неприятие). Вот нашел не очень сложное:
https://rutube.ru/video/827e51ca75c4e1062c56df2d95f3ef7a/
публикация этого же автора
https://www.leanzone.ru/index.php?option=com_content&view=article&id=1315:pochemu-1s-ne-goditsya-dlya-upravleniya-melkoserijnym-proizvodstvom&catid=55&Itemid=1322
обсуждение +/- ERP на форуме https://www.leanzone.ru/index.php?option=com_kunena&view=topic&catid=9&id=13716&Itemid=187
может червь сомнений и критическое мышление проснутся?
PS Я не со всеми тезисами и оценками Жаринова "как нужно управлять" солидарен, но в отношении адекватности ERP, пусть и из-за других аргументов, мы совпадаем
Ну ок, посмотрел.
Я не знаю, каким местом вы слушали это видео, где лектор говорит, что для управления на местах компьютерная информационная система вообще не обязательна, потому что можно карточками маршрутных листов прекрасно управляться (и да, я такое видел на предприятиях).
Т.е. критики концепции ERP там примерно 0.
Тем не менее, он также как и вы, претендует на позицию главного постановщика задач на автоматизацию системы управления, потому что (с его слов), будучи математиком, разработал уникальный алгоритм для выравнивания потребностей по комплектующим. Сомнительно, но окэй, поверим на слово.
В остальном без сюрпризов, все тот же Голдратт, барабан-буфер-веревка, про которую я вам писал. Вот 10 лет назад я общался с методистами 1С про это, про цеховые кладовые, про перемещения "точно в срок", и как будто дежа-вю сейчас.
Кстати, обратите внимание, это все хозяйство не только вы с ERReactioning, и данный товарищ хотите приватизировать, есть такая вот вещь:
"Чем LRPi отличается от обычной ERP
https://vc.ru/id682039/203068-kak-lrpi-sistemy-pomogayut-avtomatizirovat-upravlenie-proizvodstvom?ysclid=msgh0h916315391410
В отличие от вас, они не страдают глупостью отказа от слова planning в названии.
И я кстати вообще не понимаю, почему вдруг при переходе на вытягивание мы отказываемся от слова "планирование" (настолько что аж название системы ERP срочно надо менять, когда там давно уж по факту и тянущая и толкающая схемы есть).
Мы получили заказ покупателя, обещали исполнить его к 30 января, производство будет выполняться с 15го по 29е, заказываем материалы на 14е.
Мы "реагируем" на заказ покупателя, но тем не менее все еще "планируем" производство и поставки материалов.
Директор производства знает что будет делать следующий день, неделю, месяц? Знает - потому что у него есть план, расписание исполнения заказов.
Нет же такого, что он приходит в цех в неведении и начинает "реагировать"? )
Вы позвоните, грубо говоря, в шиномонтаж осенью, там полчаса весь цикл производства услуги занимает, и удивитесь, в половине случаев вам будет предложено записаться и подождать, то есть вас поставят в ПЛАН.
На РБУ бетон закажите в сезон, то же самое, скажут - можем поставить в ПЛАН завтра-послезавтра. Да, планирование краткосрочное, но это все еще планирование, никто вывески не бежит менять на системах.
Короче говоря, с этим "отрицанием планирования" странную вы себе выбрали нишу, оппонентов в виде не знающих о вас "вендоров", и вообще род занятий.
Можно мне больше в подтверждение "правоты" такую "критику ERP" не присылать? Ну скучно.
У меня простая логика:
(1) Для среды, где прогнозирование возможно - надо этим обязательно пользоваться, но там где прогнозы перестают работать, планировать нельзя (нужно реагировать)
(2) Позаказное производство, которое вы описываете, конечно не открытие. Вопрос перехода "количества в качество": предприятия, которые выпускали массовую продукцию (холодильники, одежда, автомобили, мебель,.. - практически все промпроизводства) на основе координации месячных ПЛАНОВ деятельности (ERPlanning), попали в среду когда они для выживания в конкурентной борьбе должны массово выпускать персонализированную продукцию (как пример, Даймлер в Европе за 1е полугодие 2010 года не выпустил и 2х одинаковых грузовиков, т.е. полгода выпускал неповторяющуюся продукцию). Т.е. актуальна следующая постановка задачи: как массовое производство перестроить в поток персонализированных изделий, когда клиент не готов ждать 15 дней (готов ждать не более 3х дней), т.е. когда описанный Вами классический цикл заказного производства не приемлем по длительности (время производства существенно больше допустимого времени ожидания клиента), когда переход с работы партиями (сначала 1000 белых, потом 1000 черных) на поток разных единичных изделий (1 красный, 1 голубой. 1...) - это огромная потеря производительности и рост логистических сложностей (аналогия новой постановки задачи: мы производили и продавали раньше в год 10 млн автомобилей 2х цветов (каждый цвет - своя комплектация и трудоемкость), планируя/чередуя выпуск белых и черных авто, а сейчас должны продавать те же 10 млн. автомобилей в год, но 64К цветов, при этом последовательность цветов автомобилей (у каждого цвета - своя трудоемкость и комплектация) на производство мы можем узнать всего за 3 дня, т.е. привычные сроки планирования и производства по плану не сработают). В такой постановке задачи ни решения основанные на планировании, ни решения основанные на классическом позаказном исполнении (то что хорошо умеет делать ERP) не приемлемы (1) по производительности, (2) времени производства и (3) затратам. И нужное решение не реализуется логиками ERP, потому что оно радикально другое реагирующее (я ему придумал название ERR).
Т.е.
(1) Я не продвигаю какое-то "свое" решение, которые Вы мне приписываете
(2) Я говорю о том, что в текущей среде инструментарий ERP не способен дать приемлемых результатов, нужно идеологически другое решение/логики, которое я называю противоположным планированию термином ERR
(примеры (1) и (2) можно посмотреть в организации производства и цепях поставок Тойоты)
(3) Я призываю вендоров обратить внимание на новую постановку задачи (начать изучать, чтобы разрработать на потребность промышленности адекватное решение)
И я искренне не понимаю, почему Вы категорически (не желая обсуждать и аргументировать по смыслам) эту мою логику отвергаете!?
Я бы мог понять ситуацию: мы начали эту постановку задачи обсуждать, и Вы нашли бы в ней ошибки, и поэтому предали ее и меня забвению. Но ведь Вы не хотите даже думать о том, чтобы ее обсуждать?
В чем дефект вышеописанных мною рассуждений в этом сообщении, сможете сформулировать (и желательно без выражений типа "каким местом Вы думаете")?
Мои сообщения уже становятся смешными - зарекалась свинья в грязь не лезть да на первой луже и разговелась.
возможно вас ждет открытие, но прогнозирование и планирование - разные слова и я только что объяснил почему (но вы очевидно не читали что даже у шиномонтажа есть план).
(2) Позаказное производство, которое вы описываете, конечно не открытие. Вопрос перехода "количества в качество": предприятия, которые выпускали массовую продукцию (холодильники, одежда, автомобили, мебель,.. - практически все промпроизводства) на основе координации месячных ПЛАНОВ деятельности (ERPlanning), попали в среду когда они для выживания в конкурентной борьбе должны массово выпускать персонализированную продукцию (как пример, Даймлер в Европе за 1е полугодие 2010 года не выпустил и 2х одинаковых грузовиков, т.е. полгода выпускал неповторяющуюся продукцию). Т.е. актуальна следующая постановка задачи: как массовое производство перестроить в поток персонализированных изделий, когда клиент не готов ждать 15 дней (готов ждать не более 3х дней), т.е. когда описанный Вами классический цикл заказного производства не приемлем по длительности (время производства существенно больше допустимого времени ожидания клиента), когда переход с работы партиями (сначала 1000 белых, потом 1000 черных) на поток разных единичных изделий (1 красный, 1 голубой. 1...) - это огромная потеря производительности и рост логистических сложностей (аналогия новой постановки задачи: мы производили и продавали раньше в год 10 млн автомобилей 2х цветов (каждый цвет - своя комплектация и трудоемкость), планируя/чередуя выпуск белых и черных авто, а сейчас должны продавать те же 10 млн. автомобилей в год, но 64К цветов, при этом последовательность цветов автомобилей (у каждого цвета - своя трудоемкость и комплектация) на производство мы можем узнать всего за 3 дня, т.е. привычные сроки планирования и производства по плану не сработают).
Я 15 лет назад работал на производстве одежды, и там вариабельность рост/размер верхней часть / размер брюк / обуви / шеврон / логотип точно так же делали каждый комплект уникальным, и как-то все своими силами удалось запрограммировать в системе управления и не жаловаться на вендора. Это было на 1С:УПП, которая тоже позиционировалась как решения класса ERP, хотя и не называлась так.
Единственное, что в данном случае имеет значение - приоритет заказов и время переналадки на другую продукцию (например, покрасить можно почти сразу любой краской, а вот загрузить металлический лист другой толщины или другую ткань под раскрой станков ЧПУ - займет время).
Вы не понимаете смысла, который рынок вкладывает в аббр. "ERP", потому что не работаете с этими системами лично и не знаете их возможностей, а своего Заказчика путаете и сбиваете с толку вот этими "умозаключениями".
В такой постановке задачи ни решения основанные на планировании, ни решения основанные на классическом позаказном исполнении (то что хорошо умеет делать ERP) не приемлемы (1) по производительности, (2) времени производства и (3) затратам. И нужное решение не реализуется логиками ERP, потому что оно радикально другое реагирующее (я ему придумал название ERR).
Да госсподи, вы отрицаете "прогнозирование", а не "планирование", останьте уже от него!
Посмотрите как люди прекрасно употребляют слово "планирование" в вашем "тянущем" варианте:
Тянущие системы – это такие системы планирования и организации производства, в которых сырьё, материалы, комплектующие подаются с одной операции на другую по мере необходимости (т.е. жёсткий план-график отсутствует).
При работе по тянущей системе на каждом производственном участке создаётся строго определённое количество деталей, узлов. Последующий участок заказывает и вытягивает с предыдущего участка изделия строго в соответствии с нормой и временем производственного потребления.
https://studfile.net/preview/11003215/page:3/
"Логиками ERP", по моей оценке многое из вами описанного реализуется из коробки, либо с минимальными доработками.
А ваша оценка на чем основывается, если вы например с 1С:ERP ни дня, похоже, не работали, и не понимаете где типовое решение 1С, а где ЛАДа? )
Понимаете, вот у научных диссертаций есть градации, для кандидатской можно написать какую-либо "методику", для докторской более уместно замахнуться на "методологию", а вы сразу прыгаете через 3 ступени и отрицаете целиком какую-то ОГРОМНУЮ ОБЛАСТЬ ОТРАСЛЕВЫХ ЗНАНИЙ, в которых откровенно плаваете? )
Именно что продвигаете, ваши заявления можно сравнить с тем, что какой-то фельдшер без ученой степени пинает и отрицает какую-то сферу, например, в онкологии химио терапию, и заявляет что придумал новое средство (а потом скромно добавляет, что оно пока не готово, надо "обсуждать", а по факту там та же химия, только с другим названием).
Преклонение перед Благословенным Западом я еще понимаю, но перед колониальной Японией, которая горбатилась за 3 копейки в послевоенные годы, и ввела в словарь отдельное слово (Кароси (яп. 過労死, букв. — «смерть от переработки») — японский термин, обозначающий внезапную смерть на рабочем месте или смерть от заболеваний, вызванных хроническим переутомлением и стрессом из-за чрезмерной работы)... Ну такое.
Хотите дешевые и качественные машины - просто надо больше и усердней работать и меньше жрать, вот и весь японский рецепт.
А коли вы при этом помрете прямо на работе, так это было не зря, а на пользу вашей Дзайбацу, в благодарность за вас директор - отец в вашей второй семье поднимет в кабаке с гейшами рюмку сакэ и скажет тост "так лучше, чем от водки и от простуд!"
А то что вы говорите, "способен", "не способен" - так вы же не обладаете экспертизой, слышали звон да не знаете где он, "лоскутная оптимизация" и т.п.
И что за звон примерно ясно - на каждом предприятии кто-то да ругает свою КИС, кому-то сложно с компьютером работать, кому-то она мешает воровать, начальство оправдывается ею за низкие резульаты, но вот эти голословные заявления "нужно идеологически другое решение", от человека путающегося в словах, ну смешно.
Да каких вендоров вы здесь призываете - я один тут!
Решения есть для промышленности разные, например ИТРП, если вам типовая 1С:ERP не нравится, еще там разные существуют...
Вы же до вчерашнего дня не знали что в 1С:ERP есть тянущая схема, решили что это ЛАД сделал, так вам что бы все что на рынке есть изучить, не хватит и года!
Так вы и не думаете изучать что там есть, вместо этого вы пишите почему-то сюда (буквально в Спортлото, как в песне Высотского), что мол вендорам надо у вас чему-то там поучиться - как правило, вольному пересказу Голдратта и прочих.
Для чего, очевидно, следует направить к вам в командировку методологов и потратить миллиона 2-3 ФОТ на это (а они кстати ездят и учатся, только собирают и обобщают успешные прорывные РЕАЛИЗОВАННЫЕ кейсы в отрасли, а не нытье).
Первый вопрос будет - а вы, простите, кто? )
И ответ - я работаю на предприятиях 35 лет, многое повидал. Ну замечательно, так могут сказать о себе и 99% остальных сотрудников.
Дефект рассуждений в том, что вы не понимаете как устроена отрасль разработки ПО для бизнеса.
Например, я работал последние 8 лет в крупном банке.
Который, в т.ч., может себе позволить, разрабатывать КИС полностью с нуля (собственно, он может себе позволить поддерживать свой дистрибутив linux и свою JDK), такое удовольствие, как вы подметили и длиться долго, и стоит очень дорого, условно от 500млн.р.
Потому что наймут в штат большую "крутую" команду, директоров, руководителей направлений, архитекторов таких и сяких, девопсов, программистов, аналитиков, тестировщиков, и она просто за то что на работу ходит за год-два все прожрет.
Так еще и без гарантии успеха, когда даже в богатой компании 10 бездарей стейкхолдеров (не владеющих предметом и нанятых по блату) тянут одеяло на себя, они похоронят любой проект.
Компания поменьше, например, могла бы деать КИС не совсем с нуля, а взять основой платформу 1С (пока еще не ERP, а голую платформу 1С), и потратить, допустим 100млн.р. на ресерч и разработку. Я знаю такие компании, все это реально, просто нужно погружаться и заниматься.
Компания еще меньше, не располагающая такими бюджетами, ВЫНУЖДЕНА БРАТЬ ЧТО ДАЮТ, например 1С:ERP, или ИТРП, или вообще что-то типа 1С:КА, а то и 1С:БУХ, или еще что-то отраслевое, тратить месяца перед покупкой, слезно просить франчайзи чтоб сделали хороший пресейл, смоделировали ее процессы и высветили места (гэпы), где компания может себе позволить СКРОМНЫЕ ДОРАБОТКИ (слова "радикально другое", "идеологически противоположное" выбросьте из лексикона, не по Сеньке шапка такими словами бросаться без денег).
И здесь можно будет, допустим, сэкономить до 50млн. И да, предется меньше умничать, указывать как должно быть в идеале, а больше изучать то что уже сделано неглупыми людьми, подстраиваться под типовые процессы принятые в отрасли, так зато и доработок будет немного, может справиться несколько или даже один человек из ИТ отдела компании (но их нужно еще уметь нанять туда, что вообще не просто).
И наконец, ларек с колбасой на обочине дороги НИКАКИХ ДОРАБОТОК ПОЗВОЛИТЬ НЕ МОЖЕТ себе, роскошь изобретать колесо ему не по карману, он берет т.н. БАЗОВУЮ версию 1С:Бухгалтерии без возможности внести изменения (она в 3 раза дешевле) и не жужжит, потому что если он такой умный, то где его деньги? (с).
Но при этом, в данном ларьке может найтись энтузиаст (возможно он же и владелец ларька), который будет "в одну каску" пилить свою систему по ночам, она будет очень хороша и понравится его товарищу, потом еще одному, и еще, а потом она тупо за счет 1 талантливого и энергичного человека заполнит целую нишу рынка ПО, как это не раз бывало - ну, а даже если не взлетит, все опыт, намного полезней чем сидеть и ныть.
Я в принцпе побывал в шкуре и заказчика, и исполнителя, поработал в крупных и в мелких компаниях и понимаю в чем плюсы и минусы того или иного варианта, отношусь ко всем перечисленным категориям с уважением.
А вот к вашей позиции, после ознакомления с вашим творчеством, проникнуться чем-то таким не могу при всем желании, потому что вы
1) не эксперт по данному типу ПО и
2) вообще не участник рынка данного ПО, и не понимаете как он сложился, как развивался в какие года, что из себя представляет сейчас, цепляетесь неуклюже к одному слову в аббр. ERP и умничаете, не понимая, что она имеет довольно широкий охват и включает в себя в современных релизах в т.ч. ваши хотелки из вашей т.н. "статьи".
Причем, заявляете себя Заказчиком и тут же сами же жалуетесь что денег у организации нет - ну так откуда такие амбиции тогда?
Не серьезно.
Возвращаясь к теме статьи.
"Для профессионального роста важно сохранять способность «обнуляться». Заходить в знакомую тему с установкой: возможно, здесь есть смысл, который я раньше не видел. Это не отказ от опыта, а умение временно отодвинуть привычные выводы и посмотреть на ситуацию свежим взглядом".
Из опыта в ИТ (до ИИ-период) поделюсь кратким кейсом: как посмотрели в ИТ-компании свежим взглядом на процесс найма.
1. Возникла в организации необходимость привлечения рекрутмента для набора персонала.
2. Определили план набора, сроки, бюджет, показатели рекрутмента (базовые метрики).
3. По истечении n-месяцев была уже накоплена аналитика и обратная связь от внутреннего заказчика (руководителей).
Набор линейного персонала продаж, бэк-офиса не вызывал нареканий, по основному производству (core) возникли вопросы в качестве обратной связи от менеджеров.
4. Участие финансистов/экономистов - прямое:
а) доля ФОТ в бюджете ИТ-компании превалирующая, поэтому, определяющая,
б) стоимость набора персонала (как процесс) распределяется по методу ABC-costing по видам деятельности,
в) экономика труда рекрутмента через учёт и анализ взаимосвязи разных метрик показал, что основным драйвером затрат стал набор в определенных рабочих группах: стоимость найма, стоимость ранней текучести кадров - в течение испытательного срока, стоимость повторного найма, стоимость времени непосредственных руководителей, стоимость вынужденных "простоев" и пр.
5. В качестве возражений со стороны непосредственных руководителей основного производства были: "очень длительный срок закрытия вакансий", "ошибочный подбор", пр. Со стороны рекрутеров - "не четкие требования в заявках", "непроработанный онбординг" и т.д.
6. Как в лучших традициях "бережливого производства": раскатывая экономику найма справа налево, к исходной точке заявок, - определили, что фактически непосредственным руководителям в этих группах приходилось тратить тоже самое время на разбор резюме, первичные собеседования, что до привлечения дополнительного ресурса по рекрутменту.
7. Решение было не обучать рекрутеров дополнительным техническим знаниям в ИТ (постоянно меняющиеся), а найти специалиста с техническим бэкграундом (инженер-программист), который "зашёл в знакомую тему с другой установкой" - стал ИТ-рекрутером.
Это решение позволило, как здесь пишут, "вытягивать", по мере необходимости, процесс найма специалистов с узкой технической экспертизой - как по скорости (конверсия, точность подбора), так и по качеству (процент успешно пройденных испытательный срок).
От не эксперта эксперту типичная картина (со всеми скидками ко мне, как любителю/чудику: "что вижу, то и "пою", как умею"):
Завод: 7 000 сотрудников
Высокотехничная сложная продукция: 20 000 деталей (говорят, что каждый экземпляр готовой продукции – уникален)
Единиц оборудования: 1500 штук и постоянно обновляется парк
Средняя длина технологического маршрута обработки детали: от 10 операций
Альтернативность маршрутов (на каком именно станке из доступных можно выполнить одну и ту же операцию): возможна
Управление осуществляется IT ERP решением, в соответствии с идеологией которого, на основании нормативов расхода материалов и нормативов времени обработки на операциях, до начала очередного месяца (25 числа предыдущего месяца) рассчитываются исполнимые подетальные пооперационные планы работы предприятия на месяц в стиле:
«11/08/2026 с 10.00 до 11.30 на станке с id 718 должна вестись обработка партии 30 штук деталей id 11237 (операция 7)»
Т.е. предполагается enterprise комплексная и согласованная работа смежных подразделений:
Все на основе нормативов от соответствующих служб, с гарантией, что предложенное расписание всем нормативам соответствует (= может быть исполнено в соответствии с нормативами) + с гарантией, что подобранные расписания оптимальны по предъявленным критериям оптимизации (скорость, загрузка/простои оборудования/операторов, стоимость, качество…..). Сказка и мечта под названием "Все произойдет так, как мы спланировали"…
Реальность:
которые сделали «идеально рассчитанный план» не исполнимым (карета превратилась в тыкву).
это при внедрении не факт, что на фоне вышеописанных сложностей будет обнаружено и решаться…
Так на заводе появляется дорогущая ERP-игрушка, которая основное свое назначение (исполнимое подетальное пооперационное планирование ресурсов предприятия для выполнения заказов точно в срок) исполнить, увы, не способна. Концепция подетального пооперационного планирования срабатывает только в очень узкой области применения, где указанной изменчивости и/или размерности (примитивные производства «в два действия») НЕТ!
И попытка сказать IT-шникам, что такое ERP-решение (концепция подетального пооперационного планирования на основе нормативов) не работает, встречается ими немедленно агрессивно в «штыки» - Вы не сертифицированы, Вы не понимаете как устроен процесс разработки IT продуктов, мы все знаем/умеем, у нас это уже сделано (обещать не значит жениться), нам общаться с «чудиками» недосуг, Вы сначала купите, а там мы чего-нибудь придумаем/адаптируем,… В итоге получается устойчиво воспроизводимый результат: автоматизация хаоса в идеалистическом его представлении "отсутствия изменчивости" = модель управления «сферический конь в вакууме».
В турбулентной среде изменчивость и размерность на порядки возросли, и поэтому, бог с ним, с ERP решением подетального пооперационного планирования на основе нормативов, оно просто в новых условиях стало не нужно (не надо тратить силы на его "спасение", т.к. это «дохлая лошадь»). Нужен новый класс решений на основе реагирования (никакого планирования от слова СОВСЕМ), но тут IT-шники опять занимают позицию – а какая разница (говорят они) «слева направо или справа налево» нам рассчитывать наши подетальные пооперационные планы!? Неожиданно, я могу с ними в этом полностью согласиться!?))) Действительно, вне зависимости от того, как в ERP разворачиваются подетальные пооперационные планы, результат будет одинаково неприемлемым!!!! Из рационального: если для развертывания ресурсов слева направо (планирование на месяц) в ERP присутствует матаппарат и логика расчетов, то для развертывания в обратную сторону (вытягивание от заказа или реагирования на спрос) – его нет от слова совсем (кто и как определяет размер партии Канбан и точку запуска, где и в каких размерах должны быть супермаркеты Канбан на основе текущих возможностей операций, как справляться с огромной размерностью и изменчивостью задачи, …). Все заявления, что в 1С ERP это есть – откровенная наглая ЛОЖЬ!!!! Вытягивающее планирование, как сущность 1С не известна (попробуйте ввести "вытягивающее планирование" в контекстном поиске на офсайте 1С и вы все поймете о его значимости и степени реализации в решениях от 1С)
Что я хочу своим текстом сказать не как программист (хотя я учился на программиста и работал программистом почти 10 лет), а как Заказчик (постановщик задачи): пока IT отрасль не снимет с себя нимб всезнаек (им все уже известно и разработано), не сядет за парту и не получит компетентность управленцев и производственников (чтобы понять проблематику своих Заказчиков, изучить физику и смысл новых подходов/решений, которые здесь и сейчас представители IT даже понять не в силах (отстали из-за уверенности в том, что уже все придумали)), не перестанет вталкивать в качестве универсальных свои концептуально допотопные сертифицированные ERP шаблоны подетального пооперационного согласования работ на основе нормативов, ничего хорошего в области управления производственными предприятиями из под ее пера не выйдет.
Наконец-то конкретика пошла.
Во-первых, какое конкретно решение?
И да, если это не 1С, есть такие вендоры, которые тупо не дадут никому модифицировать код, и решение превратится в чемодан без ручки.
Во-вторых, вы говорите об идеологии конкретного решения, а ругаете все семейство ПО класса ERP, утверждая что идеология лобой ERP системы = помесячное жесткое планирование без возможности корректировок по ходу исполнения плана (это не так, и именно здесь и есть дефект рассуждения)
Приведите источник, откуда вы взяли тезис, что это про 25 число именно "идеология", а не частная настройка системы на данном предприятии.
А ни на каком предприятии не сбывается план до запятой, и тем не менее все как-то живут, но жалуетесь что решения нет только вы.
Ну лет 20 назад я бы допустил что там предел сложности по железу, а сейчас дешевые процессоры имеются с десятками ядер, ОЗУ огромные объемы на серверах, и самое главное, быстрые SSD.
Сейчас даже огромные СЛАУ можно на GPU решать, что там говорить...
В данном случае вопросы точно к прикладному коду решения и способности персонала его оптимизировать.
И да, это требует квалификации и инициативы ИТ персонала предприятия, а также способности убедить и замотивировать их, что этим вообще надо заниматься, способности найти квалификацию на стороне, если свои не вывозят.
У меня в практике вообще был случай когда один парнишка программист, бывший боксер, позволил грузить в движения регистра накопления 1С произвольные даты из екселя, в результате чего там появлялись записи 0010 года от Рождества Христова, и итоги за 2000 лет пересчитывались на многострочном документе - на 4-5 часов вешая базу данных.
И весь ИТ отдел был неспособен понять, что происходит и почему так, пока я не докопался.
Сидели и умничали, что "система не справляется", а дело было вообще не в бабине (известно кто сидел в кабине). После исправления этого кода документ проводился практически мгновенно.
еще один довод в пользу вашей затеи "работать без запасов с колес"? )
+ еще второй довод в пользу вашей затеи "работать без запасов с колес"? )
а приемка как процесс вообще есть в плане, или план составлен системой так что всем до лампочки, что материалов нет и качество новых партий плавает?
ну так норматив снижайте, если оборудование старое, сами догадаться не можете?
ну так норматив и на переналадку снижайте, снова неразрешимая проблема?
а кто дал указание оператору "нагнать время", не хочет ли ответить своей зарплатой за запоротую партию?
а выводы на будущее руководители сделать не в состоянии?
ну тут уж явно ERP система виновата, просто надо ее выкинуть и все наладится!
в какой "вдруг" они оказались "сложнее в обработке"?
программа станка сама себя переписала и стала работать дольше?
это люди сделали, и они смогут подсказать причины, почему так вышло (а могут и наврать, и начальник должен быть в состоянии установить это), с тем чтобы в следующий раз учесть риски, или вообще не давать им невыполнимых в такой короткий срок заданий, если это физически невозможно.
опять же, кто принимал резцы?
если такого не избежать, меняйте норматив.
тара вообще-то подлежит учету в той же проклятой ERP системе, и если ее нет, значит учен не поставлен и инвентаризация не проводится.
но это видимо просто алгоритмы ERP системы украли тару и сломали погрузчик, просто нужно ее поменять на более прогрессивную.
а больше ничего клиенты не сообщили?
может они еще и после отгрузки будут менять состав изделия, нет?
или вы такой контракт с клиентом подписали, где он может ставить вас в коленно-локтевую и убытки заставлять терпеть, а виновата ERP система? )
и опять, если там цвет изменился, и полуфабрикаты у вас все те же самые остаются, это можно все спокойно пересчитать по фактическим отчетам производства за смену.
но вообще я думаю, вы это только что выдумали, заказ ушел в производство и тут вдруг клиенту позволено его поменять, ага.
так я и на войне могу командиру не отчитываться что происходит, или "значительно искажать информацию", и никаких адекватных (про идеальные молчу) планов он разумеется составить не сможет.
в итоге мы потерпим пражение, а меня расстреляют, а кто виноват, кроме меня?
вы описываете картину, где всем на все плевать, и по отношению к системе ERP обязанностей никаких никто за собой не чует, а вот требовать с нее что-то и ругать - за уши не оттащишь.
что-то мне подсказывает, что сверхурочные платили (или неужто ТК нарушали?) бедным сотрудникам которые месяцами в потолок плюют, а в итоге в их зоне учета бардак.
Слова не мальчика, но мужа, и не побоюсь этого слова, Консультанта с большой буквы К.
Я надеюсь, вы так в отчете и написали, что мол пытались, но невозможно!..
Тейлор в 19 веке догадался встать рядом с рабочим с секундомером, а теперь вы по записи с камер замерить реальную длительность операции не в состоянии - не говоря о логах станка ЧПУ.
Браво.
Знают, но не хотят.
Ну тут знаете, нужен конечно "математический аппарат", академика звать как минимум, тонны в м2 пересчитать, зная толщину и плотность, вряд ли так просто как мы в 3 классе начальной школы изучили.
Это и остальное что вы тут описали никакого отношения к системе ERP не имеет - это хаос на производстве, да. И лечится это не "радикальной сменой идеологии", а увеличением в данном случае нормативов, если они неадекватны, учетом рисков и разных факторов при расчете плана, добавлением планируемых доп. периодов на ранее неучтенные процедуры и т.п.
Не перекладывайте с больной головы на здоровую, речь о наведении порядка на производстве, и вроде бы этим консультант и должен был заняться, нет? )
Еще раз. Практически все что вы перечислили (кроме 1 тяжелой операции расчета плана, которую надо оптимизировать), не относится к проблемам ERP, к ее "идеологии". Есть учет, есть планирование, есть план-фактный анализ и корректировки планов. Периодичность планирования (ваш пресловутый месяц) не константа - для вашего случая можно взять неделю, 3 дня, 1 день, но то что вы вообще решили отрицать планирование, раз на предприятии бардак, это странно и по-детски.
Эта игрушка вам не нравится, нести другую, а какую вы сами не знаете? )
Так а вы бы начали с того, что изложили фактуру (а не в конце беседы), с ней можно работать хотя бы.
Вы же вместо здрасте вываливаете свои странные, на мой взгляд, глубоко ошибочные и токсичные выводы в стиле, что "на рынке ПО все п;%;№;сы, а вот я - Д`Артаньян!", в итоге получаете симметричный ответ.
И тем не менее, что можно противопоставить подетальному пооперационному планированию на основе нормативов?
1) Не подетальное?
Так у вас (или на Тойоте) конечное изделие на что разузловывается? На детали.
Ну давайте просто зайдем в цех и прокричим "ребят собираем Ладу Гранта (Тойоту Камри)!", с кого потом спросить, когда колеса забудут прикрутить, если подетальное планирование не случилось и детали в задании на сборку не указаны? Ребята сами догадаются что делать, в том числе те, кого вчера наняли по объявлению на остановке? )
2) Не пооперационное?
На станках что выполняется? Операции. Программу какую грузить в ЧПУ, если непонятно, какая операция-то? Это вам не пианино, где сымпровизировать можно было бы. )
3) Не на основе нормативов?
А станки что обрабатывают? Материалы, внезапно, поступившие по нормативу.
Иронично, но вы ж там сами предлагали без запасов же работать, были бы большие запасы можно было по факту на неснижаемом остатке кое-как выезжать, а тут получается без отпуска по нормативам, вообще производство встанет. )
У вас сейчас единственная озвученная проблема конкретно по ERP системе - в оперативном пересчете планов, и да надо разбираться с тем, что там технически этому мешает, а вы предлагаете вообще выкинуть даже то что есть, ну это замечательная, взрослая зрелая позиция, 5 баллов.
Это в том смысле что вы ленивы в плане изучения материалов, и занимаете позицию "чукча не читатель, а писатель", а писанина откровенно так себе (и это не мое мнение, а Хабра).
Сертификация занимает пару недель подготовки, но у вас за это время мир перевернется, так как сейчас знания о том "что там на рынке" околонулевые.
А вы думали, как будет? Бесплатный пресейл и тщательное моделирование проводят с теми потенциальными Заказчиками, которые демонстрируют готовность адаптации процессов под отраслевые бест практикс (ну либо имеют ОГРОМНЫЕ БЮДЖЕТЫ для реализации хотелок).
Бедные и конфликтные потенциальные заказчики никому не интересны.
Общаться с вами - это же тратить чей-то ФОТ, и вы же не стажеров хотите отвлечь от основного занятия, а методистов, их мало и они с научными степенями дорогие и капризные.
И там не "сначала купите" ПО, потому что "коробки" 1С:ERP в магазинах не распространяют.
А купите проект внедрения миллионов на 50, но вы же с вашими замашками на предпроекте заявите такие требования, которые не уложаться ни в какой бюджет.
Другими словами, лично вам, познакомившись с вами, коробку 1С:ERP даже купить не дадут, потому что никому из франчайзи (т.н. Центров Компетенции по Производству - у фирмы где я был учредителем был когда-то такой статус), не нужен заведомо провальный кейс проекта вредрения, чреватый скандалами, судами, и в конце которого точно не будет положительного отзыва, который нужен для отчетности вендору.
Вы повторяете тезис, который вообще не в вашу пользу - у вас на предприятии хаос, а виноваты почему-то ИТшники, не смогли автоматизировать хаос.
А я больше скажу - и учета никакого не надо, это же все тоже "дохлая лошадь"! )
Я вот знаю историю когда на хлебозаводе процентов 10-20 хлеба ежедневно воровалась (целые тележки через дырку в заборе выталкивали) и уходила налево в различные частные ларьки по городу.
Еще на машиностроительном заводе закупались материалы централизовано, а из них мастера 50% времени точили всякие изделия по "шабашкам", и вывозили с завода столько всякого, что иногда на легковых автомобилях масляные стойки вытекали, настолько много железа грузили в багажник и салон. )
Так что да, вот эти отпуски в производство по нормативами, это от лукавого, берите всего сколько надо!
а потом "Тащи с работы каждый гвоздь, ты здесь хозяин, а не гость!" )
Надо как на Тойоте (со слов ваших знатоков, там себестоимость же всем по боку), чисто кеш флоу считаем и нормально - как в анекдоте - бакс на рубли меняем 1:1, какая прибыль не считали пока, но обороты бешеные! )
Насчет матаппарата - чья бы корова мычала, в вашей знаменитой статье 0 (ноль) формул, а в 1Сине при вытягивании по крайней мере худо бедно разузловывание от заказа покупателя посчитается и задания на производство и комплектацию сформируются, интересно как это произойдет, без мат аппарата, магией? )
А в какой момент у нас "вытягивание" стало равняться "Канбану"? )
Вы же просто подменяете понятия.
У вас проблемы с памятью?
Это у вас как раз регулярно проскакивает ложь (начиная с "лоскутной оптимизации"), и вот это утверждение "сущность 1С не известна" тоже ложь.
Я 2 поста назад вам привел ссылки из поиска яндексом, и там как раз была инструкция какие кнопки нажимать в 1С:ERP, для включение того самого "вытягивающего планирования", а то что вы не понимаете смысла слова "партнер", "франчайзи", и почему оно было на сайтах ЛАД и 1БИТ, а не 1С, говорит лишь о том, что вы никогда не участвовали в проектах внедрения 1С:Предприятия, потому что именно фирмы 1С там не будет в 99% случаев, а будет местный партнер.
Почему на сайте 1С этого, и многого другого нет?
Да потому, что исторически сложилось так, что 1Сину активно пиратили, в результате чего документацию на ее ПО можно было получить легально ТОЛЬКО в бумажном виде (желтые книжки, которые никто не читает) и все, а со сканированием и выкладыванием в интернет фирма 1С активно боролась!
И полной документации на систему на ее сайте тупо нету (ага, чтоб вы спиратили программу и на их же сайте учиилсь ей пользоваться?).
Еще информация есть в учебных курсах (тоже в бумажном виде), ну а франчайзи иногда выкладывают переработанные самостоятельно кусочки, когда слишком часто у пользователей вопросы возникают одни и те же, как сейчас.
И да, я допускаю, что там могут быть некие особенности, и даже баги, но внести в эту часть доработки (1% от всего функционала), это в 100 раз быстрее и эффективнее, чем с нуля что-то городить с "противоположной идеологией", которую еще и вы сами сформулировать не способны, а хотите "дискутировать" с "вендорами".
И по итогу 10 лет работы программистом не поняли, что программисты - они про алгоритмы, поэтому выдаете им на Хабр кучу лозунгов, 0 формул и 0 алгоритмов вашей великолепной будущей системы, неудивительно что рейтинг статьи минус один и там 0 конструктивных комментариев.
Заказчик - сторона по договору, а не то что вам кажется, что раз вы сидите на заводе, так вы уже и Заказчик.
Я практически уверен, что договорных отношений конкретно с вендором у вас нет - максимум это корп. поддержка у партнера.
Когда-то я сам сидел в должности архитектора на такой корпоративной поддержке у франчайзи между заводами на 10000 юзеров и ПАО 1С.
И да там были большие проблемы с реакцией от вендора. И хотя мне удалось победить и достучаться по этому кейсу до 1С, это стало главной причиной, что я ушел из сообщества 1С на 10 с лишним лет и стал заниматься опенсорсом Java/Scala/Kotlin - там проблемы были не как у вас в прикладным кодом, а с платформой, и беспомощность работы с проприетарщиной, закрытой ото всех, меня на тот момент просто убивала. Но вероятность, что вы с этим столкнетесь, исчезающе мала.
И сейчас не об этом, а о том что вам делать со стороны, условно, Заказчика (что бы я делал на месте Заказчика в описанной ситуации).
Если вы заключили невыгодный договор, и Исполнитель вам не нравится (он не решает вашу проблему), расторгните его и найдите нового исполнителя.
Допустим, партнеров в вашем регионе мало, ну 5-10 со статусом "Центр компетенции по произвоству", и вам вообще никто не нравится.
Так можете вообще в штат взять программистов, сформировать команду и пусть они лично вам подчиняются по штатке, вряд ли они рискнут "одеть нимб всезнаек". )
Что до "постановщика" - писал ранее, нормальный постановщик выявляет гэпы фукнционала (что уже есть / что нужно), а не плачет о том что система в целом плоха и надо новую с "противоположной идеологией", это несерьезно. Ну, представьте что вам дали картбланш - тратьте хоть миллиард, нанимайте хоть 100 программистов, но чтоб через квартал решение было - и с чем вы к ним пойдете, с этой детской статейкой с Хабра? )
Что бы вы там не нафантазировали, у вас реально проблема в 1% функционала, производственном планировании и корректировке планов.
Не в бухе, не в финансах/бюджетировании, не расчете зарплаты и не в логистике - вы просто не понимаете, сколько всего полезного в решении с названием "ERP" - там первая буква Enterprise так-то, оно накрывает весь учет на предприятии.
Вот 1% и целесообразно переделать/доделать, а на большее, как вы сами признались, и денег-то нет.
Вот, вот, как я и сказал, представлять Заказчика в договорных отношениях вы пока не готовы, вы не вывозите переговоры с Исполнителем - для этого надо понимать что вы можете требовать при своем бюджете, а что нет.
Глупо с 1млн.р. приходить в салон Мерседес и когда вам самая младшая модель не по карману, требовать понять проблематику и продать вам джип или микроавтобус на 8 человек и требовать на встречу главного инженера.
Компетенции там, поверьте, есть, просто вас до этих людей не допустят, их время дорого, а с вами даже младший продажник 5 минут пообщавшись поймет все перспективы.
Хотите кого-то "учить", самоутверждаясь - нанимайте программистов в штат, садите их за парту, оплачивая им зарплатой это мероприятие, и дерзайте, у вас "из под пера" однозначно выйдет Шедевр! )
Но я сразу говорю - вот та статья на хабре, там оооочень немногому можно научиться, сплошные лозунги, а вот формул-то и алгоритмов вообще не густо. )
Равновато вам пока в постановщики-аналитики, наймите заодно и их готовых на рынке чтоб не оплошать.
И раз "вендоры" вам не те, пилите свое решение, хоть с нуля, хоть на базе 1С:ERP, хоть на голой 1C, хоть на турбо паскале.
Но вы же так не сделаете? )
Потому что знаете, что вас через полгода-год с завода с околонулевыми результатами выгонят в шею, и ни какого "вендора" вину уже свалить не получится. )
Я внесу свои комментарии и вопросы.
1. В вашем проекте на заводе были разработаны нормативы затрат на единицу объема ресурсов (материалов) и времени. И оценка осуществляется по затратам, исчисленных по этим нормативам.
Это снижает достоверность, т.к. анализ производится по нормативам всего завода.
Внедрите вначале комбинированный учёт: прямые затраты - по факту, косвенные - уже с использованием нормативов и коэффициентов распределения.
Соберите данные, проанализируйте динамику, разработайте методику, а потом формулируйте требования к любой информационно-аналитической системе.
2. Касательно выбора ИТ-решения.
Я не уловила причину каким образом принималось решение о выборе вендора и его продукта.
Почему выбор был сделан именно в пользу этого решения?
Были ли рассмотрены альтернативные продукты в соответствии с бюджетом и изначальным планом первоочередных задач на заводе?
Кто был заказчиком на заводе, какой был изначально задел: выстроить упручет или сразу натянуть ИАС на весь периметр?
В подобных проектах очень высокий уровень неопределенности.
Поэтому, как математик, у заказчика вы могли рассмотреть радужный (комплексный) опцион. Дерево сценариев с реперными точками, на которых принимались бы решения: остановка внедрения на определенном функциональном участке, развертывание дополнительных модулей (при успешном внедрении и появлении допфинансирования), переключение на другие ИТ-решения, выход из проекта (другие приоритеты).
Можно и семь шапок сшить из одной шкуры при желании. Так что в этом случае, с моей точки зрения, вопрос не в самом ИТ-продукте.
Эльвира, я никакого отношения к IT решению, которое внедрялось и работало на заводе не имею. Я по приглашению руководства завода (на котором накопилось очень много проблем и была сложная по экономике ситуация), вел работы по улучшению организации производства и системы управления. Поэтому мне пришлось (в той части, где мы пересекались, прежде всего в области бизнес модели и подходов к планированию) изучать действующую корпоративную информационную систему завода и сформировать мнение о ее возможностях и степени адекватности.
КИС на заводе внедрялась уже несколько лет до моего появления и продолжала с той же мерой "успешности" внедрятся и после окончания моего проекта (на сколько я знаю).
Итоговая ее судьба (мой отрезок наблюдений составил "всего" 3 года) и судьба моих рекомендаций по ее тансформации мне, к сожалению, не известны.
Я твердо знаю одно: что любым образом установленные нормативы + подход к подетальному пооперационному планированию на их основе дают неприемлемые результаты в турбулентной среде.
Я наблюдал это не на одном предприятии, более того, моя грустная статистика такова, что мне в моих проектах НИ РАЗУ не встретилось предприятие, в котором бы подход к подетальному пооперационному планированию на основе нормативов (концепция ERP, причем от разных вендоров, в т.ч. от SAP) приемлемо работал! Видимо предприятия с существенными проблемами в экономике (которым нужен консалтинг по бизнес-эффективности) - не дружат с ERP.
Моя т.з., эти предприятия работали в "стационарной среде" и успешно эксплуатировали ERP подход к управлению, но среда у этих предприятий быстро развернулась, став "турбулентной", а они продолжали управлять предприятием привычными ERP методами, что быстро привело их к экономическим проблемам.
Причина моей убежденности - огромная изменчивость в которой находятся предприятия (которую видно не вооруженным глазом), с которой подход основанный на точном предсказании нормативов справиться по-определению не в силах! Вместо точно "предсказанных оценкок-точкек" (которые должны быть предсказаны с минимальной погрешностью от факта), практически все нормативы на самом деле подвержены непредсказуемой и существенной изменчивости в большом интервале значений, который существенно превышает приемлемую точность планирования. Т.е. ERP ведет разработку долгосочных планов и координирует действия подразделений и служб основываясь на спрогнозированных заранее "точках", а реальность то другая: "точек" НЕТ, есть интервалы, в которых эти "ТОЧКИ" не предсказуемым заранее образом непрерывно перемещаются. Этот факт и является основой критики концепции ERP, каким бы образом в нем не разворачивалось бы планирование (с начала (под прогноз) или с конца (под заказ) технологического процесса).
Нужное решение - это подход к непрерывному реагированию на поток наблюдаемых изменяемых фактов, который должен быть основан на компетенциях быстрого и корректного определения истинного текущего значения параметров, и быстрого выбора согласованного решения "как наилучшим образом при таком "эквалайзере" текущих значений параметров действовать".
Я такой альтернативный подход к управлению деятельностью предприятия в такой непредсказуемой турбулентной среде назвал (авторство названия мое) ERReactioning. И вопросы, например, текущей дискуссии, которая ведется с Никитой, в том, что:
Поэтому любые вариации на тему "как более точно предсказать точку", в том числе и рекомендуемые Вами, ИМХО, не сработают.
Не знаю, т.к. вопросы не по адресу!
Могу лишь повторить уже озвученный на EXECUTIVE тезис, основанный на моем опыте:
Будучи, в т.ч. преподователем на факультете Бизнес-информатика в Высшей Школе Экономики, я имею возможность ежегодно проводить исследования новинок в области IT-решений по управлению предприятиями. Уже лет 7-8 мои студенты в курсовых работах шерстят рынок на этот предмет, причем целенаправленно ищут именно решения в области управления на основе реагирования (признаки таких систем - вытягивающее непрерывное планирование, реализованное, в т.ч. с помощью решений KANBAN). Так вот, в соответствии с этими исследованиями (а с 2022 года особый упор сделан на отечественных вендоров и прежде всего решений на платформе 1С) - комплексных решений на рынке пока нет (есть только фрагментарные попытки локального включения некоторых инструментов реагирования).
Поэтому как математик с известными мне результатами вышеприведенных исследований (не знаю, нарушу ли я какие-либо ограничения, если например, опубликую здесь последнее такое исследование одного из моих студентов!?), я не смог бы порекомендовать ни одно из известных мне решений!
Поэтому крупным своим Заказчикам я рекомендую стать компетентным постановщиком задачи (сделать нужную постановку задачи на реагирующую систему управления предприятием и цепями поставщиков) и искать исполнителя этого ТЗ, чтобы выжать из него все необходимые "соки" и добиться необходимого результата.
Опять Вы уходите в область деструктива: пытаетесь меня критиковать или отделаться!?
Предлагаю объединить усилия и с конкретикой разобраться? Меня голословные «все делается, все решается, все учитывается», как и вас не устраивают, т.к. я хочу не «поверить», а «понять», и согласитесь, в этом нет криминала!? А Вы, как сертифицированный специалист с огромным опытом работы, в этой задаче ПОНЯТЬ – просто находка для меня!
Итак: 1500 единиц оборудования (точек, вершин графа), по ним нужно провести 20 000 технологических маршрутов обработки длинной от 10 единиц оборудования (20 000 ломанных линий, векторов на единицу готовой продукции). Если в течение месяца предприятию нужно выпустить 100 единиц продукции, то нужно совместить/сгруппировать и оптимизировать все эти маршруты (на исполнимость, на скорость, затраты, оптимальность загрузки оборудования/операторов,…), чтобы к концу месяца нужные 100 единиц готовой продукции эффективно произвести. И система управления с логикой ERPlanning на основании нормативов такие пооперационные подетальные планы строит (и Вы говорите, вне зависимости от размерности, практически мгновенно, готов в это поверить), и на основании их еще и согласует планы деятельности прочих служб (закупки, обслуживание оборудования, внутренняя логистика, работа отк, формируются бюджеты, штатные расписания и т.п.)
Для примера возьмем одну из 20 000 деталей и рассмотрим алгоритм работы при формировании подетального пооперационного плана-графика для нее?
Пример детали и маршрута:
Закупаем материал в рулонах по ГОСТу (пример должен быть близким Вам с трикотажной фабрикой, я специально под этот Ваш опыт его подбирал), красим его, кроим рулон на какие-то комплекты деталей и их как-то обрабатываем (сверлим, гнем и т.п.) и потом этот комплект деталей идет на сборку конечной продукции.
Упрощаем задачу, считая, что вне зависимости от поддерживаемого номенклатурного разнообразия готовой продукции, состав и количество рассматриваемых нами для примера деталей из рулона требуется одинаковый.
Вот несколько стандартных задач для планирования:
Вносим в задачу типичную изменчивость (с которой «как мне сейчас напрасно кажется», ERP системы «не очень хорошо» вплоть до «неприемлемо» умеют справляться) и Вы мне объясняете, как эта изменчивость штатными решениями учитывается алгоритмами планирования (мне не нужны формулы, достаточно общей логики)? Итак:
Изменчивость_1 (направлений изменчивости много, начнем с этой) – это разнотолщинность материала (в общем случае, изменчивость какой-то характеристики материала, которая может оказать влияние на объем выпускаемой продукции, качество, время обработки и т.п.).
По памяти по данным клиента, которого я взял в качестве прототипа для этого примера:
По ГОСТу допускается разнотолщинность материала от 28 до 42 микрон (все, что внутри этого допуска – годная продукция).
Разница в площади материала в рулоне одного веса, но разной толщины материала S_28 vs S_42 – 40% (т.е. возможный диапазон ошибки при планировании бюджетов, объемов выпуска продукции, необходимого времени обработки 40%, в зависимости от фактической толщины материала).
Вопрос: какие данные нужно вносить в качестве нормативов для решения задач 1-3, если на момент покупки рулонов известен только их тоннаж (фактическая разнотолщинность и площадь – это «сюрприз», и точные их значения могут быть установлены только в процессе обработки рулона, т.е. во время выполнения операции)?
Я уверен, что для такой упрощенной постановки задачи адекватное решение в ERP системах должно быть, т.к. я знаю прикладное решение, которое в промышленности для таких ситуаций применяется (хочу сравнить предлагаемый IT подход с фактически применяемым «на полу»).