Я отдаю себе отчет, что общаясь с Вами (огромное Вам спасибо за ответственное отношение к нашей беседе), я общаюсь не с "владельцем" ПСР!))) И вместе с тем, я посчитал нужным/важным именно Вам адресовать обсуждаемые вопросы. Попробую свои соображения "почему" я так считаю сформулировать:
Я среагировал на позиционирования смыслов и содержания ПСР, с которого Вы начали свою статью:
Производственная система «Росатом» (ПСР) – это культура бережливого производства и система непрерывного совершенствования процессов для обеспечения конкурентного преимущества на мировом уровне.
Она была разработана на базе лучших образцов отечественного и зарубежного опыта, в частности, системы научной организации труда, производства и управления (НОТПиУ) Министерства среднего машиностроения СССР и Toyota Production System японской автомобильной компании «Тойота».
Именно такое позиционирование ПСР (на которое Вы опираетесь в своей статье) я считаю проблемой
Я вижу следующую негативную тенденцию: в ситуации, когда предприятия СПАСЕТ только смена парадигмы (не улучшения или прорывные решения (крупное улучшение в рамках текущей парадигмы), а изменить парадигму (в моей статье Вы могли увидеть, как много аспектов все сразу комплексно нужно поменять на противоположные, заменить одну систему совершенно другой)) предприятия совершают прямо противоположные действия все усиливая и усиливая власть и механизмы сохранения/совершенствования существующей системы, что только уменьшает вероятность/возможность выхода на постановку задачи РАДИКАЛЬНОЕ ПРЕОБРАЗОВАНИЕ!
Ответы в стиле "к пуговицам претензии есть?" - я отвечаю только за показатели ПСР, можно, конечно, привычно принять (я обычно только такие и слышу, т.к. та постановка задачи которую я поднимаю, увы, не имеет "хозяина" в действующих системах управления), но ведь именно эти "пуговицы"/благие намерения дорогу в АД вымащивают!
Это все размышления к моему вопросу: "когда улучшения - это ЗЛО" (аналогия про "Дохлую лошадь").
И я затеял с Вами разговор, чтобы Вы, как носитель/создатель этого сильного механизма "системы постоянных улучшений ПСР" осознавали, не только его сильные стороны (о чем была Ваша статья и с сильными сторонами я не воюю), но и опасные ограничения, когда работа на полную катушку этого механизма - это уже не благо, а тормоз в развитии предприятия.
В качестве резюме, актуальная глобальная методическая Проблема/Задача заключаются в том, как определять такие точки бифуркации для компании и как создать механизмы управления такими преобразованием в согласованной дружбе с компетенциями по постоянным улучшениям (сейчас, эти сотрудники и носители таких компетенций, де факто выступают как противники/враги задаче радикального преобразования). Ну и маленькая/локальная))) Проблема/Задача - что делать конкретно в ПСР?
Извините, если мучал Вас "не по адресу"! С наступающим Новым Годом!
Ваши декларации в стиле "не сомневайтесь, у нас все правильно" не могут служить доказательством, т.к. это не вопрос ВЕРЫ (в чудодейственную силу ПСР), а вопрос смыслов и механизмов (и я хочу разобраться, а не принять на веру)!
А Ваши ответы про обратную связь, культуру кайдзен, приоритеты "сверху-вниз",... лишь убеждают меня в обоснованности моих сомнений, т.к. нужные слова/аргументы Вы в который уже раз не приводите (значит в системе координат ПСР их нет или у них ничтожная роль, раз они не приходят вам в голову)!
Например, вы говорите о приоритетах в развитии ПСР спускаемых сверху-вниз, но это все инструменты, никак не связанные с задачей "перепланировки" (ее в принципе невозможно сделать через приоритеты и кайдзен, для ее осуществления нужны абсолютно другие инструменты, которые Вы в своих ответах как раз не упоминаете).
Все приоритеты ПСР - это направления повышения операционной эффективности в рамках существующей "планировки комнат" для решения задачи постоянного повышения "комфорта и удобства пользования текущей планировкой из 100 000 комнат". Т.е. это все инструменты работы в текущей планировке.
Мой же вопрос состоял в том, какие механизмы в ПСР есть для решения задач "перепланировки". Например мы придумали организацию деятельности, в которой вместо существующих 100 000 комнат с таким-то оснащением и функционалом, надо уйти в абсолютно новую организацию производства с 60 000 комнат, с принципиально другим оснащением и функционалом. Через кайдзены и приоритеты такая задача не решается, от слова СОВСЕМ!
А весь этот долгий диалог я затеял только из-за того, что считаю что устройство производственных предприятий РОСАТОМА надо не улучшать (методами и культурой кайдзен (терапия из витаминок и тренировок)), а радикально преобразовывать (методами директивного управления преобразованиями, для перехода в целевое состояние с другим организационным строением (нужна хирургия, вместо терапии)). Чуть подробнее эту мысль развернута https://habr.com/ru/articles/978502/
Факт_1. Предприятия (в абсолютной массе) не адекватно устроены и управляются - это корневая причина их экономических проблем и тенденции деградации (утраты рыночных позиций)
Факт_2. Как надо преобразовать устройство предприятия и систему управления на предприятии не знают (знали бы - давно поменялись бы). Поэтому это БОЛЬШАЯ МЕТОДИЧЕСКАЯ ГЛУПОСТЬ спрашивать у отдельных представителей предприятия (в рамках внедрения ERP), что они считают TO BE. Собранные таким образом "лоскутные одеяла" мнений TO BE от 40-100 сотрудников предприятия - это то же броуновское движение и сохранение неадекватности (возможно, даже ее усиление), а ни какое не TO BE, которое сделает предприятие адекватным/эффективным. Закономерный итог - проект неадекватного же устройства предприятия (тот же хаос, но с громким маркетинговым обманом TO BE)
Факт_3. ERP (от любого вендора) - это типовой (давно устаревший и не адекватный современным управленческим новациям, таким как LEAN, ISO серии 9000, ISO/TS 16949 (APQP, SPC,FMEA,MSA), ...) шаблон описания деятельности компаний (с моей т.з. не выдерживающий никакой критике). Т.е. автоматизируя деятельность предприятия по этим шаблонам В ПРИНЦИПЕ НЕ ВОЗМОЖНО вылечить не адекватность! Поэтому, ХАОС (обозванный TO BE) + ERP ШАБЛОН (принципиально устаревший) = АВТОМАТИЗИРОВАННЫЙ ХАОС (напрасно потраченные силы, время, деньги на решения, которые только усугубят печальную тенденцию деградации предприятия)
Эти 1,2,3 и нужно принять в качестве корневых причин для анализа рынка ERP и направлений его развития
ИМХО: IT отрасли нужно разработать совершенно новый ERP продукт (на базе LEAN, ISO серии 9000, ISO/TS 16949 (APQP, SPC,FMEA,MSA), ...) взамен неприемлемо устаревших ERP решений. Для этого разработчикам нужно изучить эти управленческие новации.
Факт_1. Предприятия (в абсолютной массе) не адекватно устроены и управляются - это корневая причина их экономических проблем и тенденции деградации (утраты рыночных позиций)
Факт_2. Как надо преобразовать устройство предприятия и систему управления на предприятии не знают (знали бы - давно поменялись бы). Поэтому это БОЛЬШАЯ МЕТОДИЧЕСКАЯ ГЛУПОСТЬ спрашивать у отдельных представителей предприятия (в рамках внедрения ERP), что они считают TO BE. Собранные таким образом "лоскутные одеяла" мнений TO BE от 40-100 сотрудников предприятия - это то же броуновское движение и сохранение неадекватности (возможно, даже ее усиление), а ни какое не TO BE, которое сделает предприятие адекватным/эффективным. Закономерный итог - проект неадекватного же устройства предприятия (тот же хаос, но с громким маркетинговым обманом TO BE)
Факт_3. ERP (от любого вендора) - это типовой (давно устаревший и не адекватный современным управленческим новациям, таким как LEAN, ISO серии 9000, ISO/TS 16949 (APQP, SPC,FMEA,MSA), ...) шаблон описания деятельности компаний (с моей т.з. не выдерживающий никакой критике). Т.е. автоматизируя деятельность предприятия по этим шаблонам В ПРИНЦИПЕ НЕ ВОЗМОЖНО вылечить не адекватность! Поэтому, ХАОС (обозванный TO BE) + ERP ШАБЛОН (принципиально устаревший) = АВТОМАТИЗИРОВАННЫЙ ХАОС (напрасно потраченные силы, время, деньги на решения, которые только усугубят печальную тенденцию деградации предприятия)
Эти 1,2,3 и нужно принять в качестве корневых причин для анализа рынка ERP и направлений его развития
Потихоньку продвигаемся))) Ок, следующий шаг, ПСР - это "квартира с сотней тысяч комнат", откуда работник из комнаты № 56 743 может узнать о планах на стены (какие можно улучшать, а какие нельзя)? Или он просто "кайзенит" на любые стены "не приходя в сознание"?
В том то и дело, что если ПСР занимается постоянными улучшениями и их много - это никакое не доказательство того, что ПСР не попало в ловушку стратегии "Дохлой лошади"!
"Дохлая лошадь" - это как раз про то, что Вы занимаетесь улучшениями, но того, что надо бросить как можно скорее, а не улучшать!
Попробуйте ответить на вопрос: в каких ситуациях улучшения - это ЗЛО?
К сожалению, всем нужна "справка о здоровье", а не "здоровье". Никто ради "здоровья" меняться не особо хочет, поэтому смыслы/идеи стандартов ISO серии 9000 не поняты и искажены/девальвированы. Подробнее мои мысли https://habr.com/ru/articles/978502/
Производственная система «Росатом» (ПСР) – это культура бережливого производства и система непрерывного совершенствования процессов для обеспечения конкурентного преимущества на мировом уровне.
А если модель производственной системы не адекватна современной бизнес-среде, нужно ли развивать культуру и бросать все силы на ее совершенствование? Очевидно же, что такие действия при условии "не адекватности" - это стратегическая ошибка (стратегия "Дохлой лошади" по индейцам Дакота во всей красе)! Т.к. тогда нужно бросить старую неадекватную модель (вместе с культурой постоянного ее совершенствования) и срочно разрабатывать новую адекватную (и только когда ее создадите, создавать для нее культуру постоянного совершенствования)!
Предприятие должно опираться на адекватную рынку бизнес-модель (решения по организации производства, системе управления и взаимодействию с Поставщиками и Потребителями). Если модель адекватная, то, очень вероятно, что для принятия правильных управленческих решений много данных и не понадобиться. И наоборот, если модель работы предприятия не адекватная, то ему не помогут и миллионы поступающих данных, как не управляй неадекватной моделью, ничего хорошего из этого не выйдет!
Поэтому тезис о том что для эффективного управления нужно очень много данных - очень спорный.
Действующие ERP решения основанные на функциональном подходе к управлению и прогнозах, как у автора:
Квартальный план (стратегический уровень)
Месячный план (тактический уровень)
Недельный план (оперативный уровень)
Суточный план (исполнительный уровень)
это сейчас вообще неприемлемые по эффективности решения (не адекватные современной бизнес-среде). Сейчас нужны вытягивающие гибкие процессные модели планирования и управления, чего в современных ERP решениях, увы, нет от слова СОВСЕМ (подробнее https://habr.com/ru/articles/978502/)
Переходить надо на решения, которые, увы, не поддерживается ни одним из перечисленных продуктов в публикации. Подробности раскрытия этого тезиса см. https://habr.com/ru/articles/978502/
На сегодняшний день, наиболее оптимальным подходом к решению производственных проблем (с точки зрения временных и финансовых затрат) является стратегия прогнозируемого обслуживания на основе состояния в реальном времени с применением технологий искусственного интеллекта.
К сожалению, этот тезис и, как следствие, последующие рассуждения на его основе - это ОШИБКА!
Главная цель и условие эффективного существования современных бизнес-систем - точно вовремя исполненный заказ Потребителя. "Точно вовремя" возможно обеспечить если в обещаниях клиенту по срокам учтены все работы по поддержанию работоспособности оборудования. А для этого все работы по обслуживанию оборудования должны выполняться как плановые (заранее известные) по модели, которая у Вас обозначена, как:
Предписывающее обслуживание.
Сложность такого обслуживания связана с тем, что остановки производства на предписывающее обслуживание должны быть синхронизированы по производственной цепи.
Поэтому, вроде бы очевидный чемпион по абсолютным затратам подход "обслуживание оборудования по состоянию", оказывается неприемлемым с точки зрения бизнес-задач . Т.к. цель бизнеса не обеспечить минимальные затраты на обслуживание оборудования, а обеспечить выполнение точно вовремя заказов клиентов (именно это приносит деньги бизнесу), а для этого подходит (повторюсь) ТОЛЬКО подход Предписывающее обслуживание! Поэтому стратегию применения датчиков и интернета вещей надо подбирать/настраивать не под модель "обслуживание оборудования по состоянию"
ERP построенные на идее прогнозирования и подетального пооперационного планирования - категорически устарели и не соответствуют требованиям сегодняшнего времени. Сейчас нужны решения использующие вытягивающее (реагирующее) планирование на основе КАНБАН и управление производственными активами цепи поставок как виртуальным конвейером в ТАКТ. Это совершенно разные идеологические решения!
Вопрос автору: разрабатываемые Вами ERP обладают этой востребованной сейчас функциональностью?
ERP построенные на идее прогнозирования и подетального пооперационного планирования - категорически устарели и не соответствуют требованиям сегодняшнего времени. Сейчас нужны решения использующие вытягивающее (реагирующее) планирование на основе КАНБАН и управление производственными активами цепи поставок как виртуальным конвейером в ТАКТ. Это совершенно разные идеологические решения!
Вопрос автору: разрабатываемые Вами ERP обладают этой востребованной сейчас функциональностью?
Почему в качестве инструмента для описания архитектуры предприятия используется не принятый в прикладном мире международный стандарт ISO серии 9000 (3 млн. организаций сертифицированы + неизвестное количество организаций, которые используют стандарт, но не сертифицируются), а не понятный этому миру (понятный только ITшникам) TOGAF?
Как осуществить соответствие (и кто его проведет) создаваемых описаний архитектур Организацией на ее языке ISO серии 9000 и созданный ITшниками на языке TOGAF?
Несмотря на то, что комментарий направлен не мне (не содержит вопросов к автору и не нуждается в моем ответе), а направлен на поиск единомышленников в абсолютном неприятии публикации (с великими людьми и не такое бывает) и критику бизнес-консультантов (почему то по мнению комментатора - это низшая степень компетенций в его личной иерархии), среагирую:
Краткое содержание, цели и выводы публикации (для тех, от кого оно ускользнуло):
Введение:
Проблемная область: Есть Клиенты-Покупатели - промышленные предприятия, есть IT Поставщики-Продавцы IT продуктов для управления промпредприятиями/холдингами (решения класса ERP). И автор (как эксперт от клиентов), обсуждает проблему неприемлемого качества этих IT продуктов, которое является следствием неприемлемого уровня знаний IT отрасли о своем Заказчике, которое в свою очередь, является следствием сложившегося неприемлемого стандарта взаимодействия IT отрасли со своими Заказчиками.
Цель публикации - объяснить IT отрасли, что происходит в Промышленности, показать, что то, что сейчас делает IT отрасль - неприемлемо, и призвать ее к преобразованиям (начать изучать знания, используемые сейчас в промышленности, установить корректное взаимодействие с Заказчиками, и как итог разработать нужные Потребителям IT продукты). Это разговор Заказчика с Исполнителем, на языке Заказчика
Глава 1.
Если Вы хотите корректно понять процессы происходящие в настоящее время в промышленности, то это стадия перехода из состояния "Можно работать как монополисты" (СПРОС > ПРЕДЛОЖЕНИЯ) в альтернативное состояние "Работать как монополисты НЕЛЬЗЯ" (ПРЕДЛОЖЕНИЕ > СПРОСА).
Так выглядят выводы Главы 1 в тексте публикации
Глава 2.
Объясняется радикальная разница в ведении бизнеса и устройстве предприятий, когда ты можешь позволить себе работать как монополист, и для высококонкурентной среды (когда работать как монополист - гарантированная смерть предприятию). Это две различные АЛЬТЕРНАТИВНЫЕ системы решений (система ТРЕУГОЛЬНИКОВ и система КРУЖОЧКОВ)
Это текст к в Главе 2
Так выглядят выводы к Главе 2
Главный вывод Главы 1 и 2 с корректной постановкой задачи "Что происходит и что нужно делать?":
Так выглядят выводы после главы 1 и 2
Глава 3.
В ней приведены мои оценки (как эксперта от промышленности) по текущей ситуации, с т.з. вышеописанной постановки задачи (их 9).
А теперь, в свою очередь, не могу не удержаться от удивления от позиции комментатора и оценок от сообщества ХАБРа:
Насколько надо быть ангажированным, чтобы не увидеть в статье ни одного смысла, ни одного вывода!?
Обычно, если что-то "НЕ ПОНЯТНО" в общении с КЛИЕНТОМ, то говорить КЛИЕНТУ "НИЧЕГО НЕ ПОНЯТНО" - это профессиональное самоубийство! Если ты хочешь быть полезным КЛИЕНТУ, сделай усилие, изучи его язык и проблематику, задавай уточняющие вопросы, НО РАЗБЕРИСЬ или не заявляй, что это твоя клиентская группа!? Устраивать же мне, как представителю ЗАКАЗЧИКОВ обструкцию, вместо попытки РАЗОБРАТЬСЯ - это верх какого-то СНОБИЗМА и ПРЕНЕБРЕЖЕНИЯ интересами КЛИЕНТА!?
Ваша позиция лишь утверждает меня в верности моей гипотезы об ОГРОМНОЙ проблеме в IT отрасли, которая так же мною сформулирована в Главе 2
У Вас на ХАБРе засилье экспертов от промышленности, что Вам не интересно со мной общаться (не видите в этом пользы - видите только ЗЛО) и Вы предпочитаете меня "слить" и заткнуть мне рот своими минусами!? Ни одного плюсика или благодарности за идеи и пищу для размышлений, только НЕГАТИВ!? Мои попытки общения и высказывания своих мыслей - для ХАБРа угроза что ли!? Здесь так принято бороться с инакомыслием!?
текст ИМХО немного консультантский и концептуальный.
Я - консультант, да еще и преподаватель в ВШЭ, поэтому выбор стилистики ответа, по умолчанию, у меня соответствует моей профессиональной деформации))) Конкретизируйте вопрос (приземлите меня) - попробую ответить "по человечески")))
а уже есть сторонники из числа СОБСТВЕННИКОВ бизнеса
Есть, но это прецеденты (не только МТЗ, по моему резюме можно увидеть с кем подобная постановка задачи продвигалась (везде с разной пройденной дистанцией), но это единицы), а не система, поэтому продвижение (как я понял и в соответствии с Вашим опытом) - сложное/медленное. МТЗ - это прецедент, когда проблематика не соответствующей КИС выведена на уровень ключевых проблем, которые нужно комплексно решать и консультанты выступают как постановщики задачи целевой КИС.
Интересуюсь потому как сам в последнее время сталкиваюсь с аналогичными проблема и и прорабатываю, свою, условно "методологию" резко отличающейся от классики и уже ставших классическими agile подходов.
Интересно! Поделитесь ссылкой, где я могу с Вашими идеями познакомиться (если не секрет)?
PS Опубликовал статью с аргументацией, как я это вижу и понимаю, в т.ч. по Вашей просьбе - можете с ней познакомиться https://habr.com/ru/articles/978502/
Действующая на предприятии система решений (по организации производства, системе управления, взаимодействию с Поставщиками цепи Поставок и Потребителями, по подходам к управлению качеством и надежностью процессов/продукции, логистическим транзакциям и т.п....) находятся в гармонии (соответствуют и согласованы друг с другом), но дают неприемлемый по экономической эффективности результат и вводят предприятия в системный цикл деградации: рост оборотки при замедлении ее оборачиваемости, срыв контрактов, кассовые разрывы, ухудшение взаимоотношений с поставщиками (кризис не платежей), уменьшение возможностей по уровню зарплат (кадровые проблемы) и инвестиций на развитие). И такая ситуация - это системная проблема (верна для 95% компаний).
Выход из кризиса - это радикальное преобразование действующей системы решений (по перечисленным методологическим новациям) в масштабе предприятия/цепей поставок, который позволит в разы на порядки повысить экономическую эффективность и победить цикл деградации (войти в цикл роста)
Руководство/главные специалисты предприятия не корректно оценивают ситуацию и выбирают стратегию выхода из кризиса - предпочитают методами локальных улучшений повысить эффективность действующей системы решений (ищут легких путей, верят в старые решения). Но в текущей бизнес-среде - это стратегия "Дохлой лошади" (максимально возможный эффект - рост на уровне долей процентов/единиц процентов, а это категорически не достаточно, чтобы выйти из деградационного цикла)
Поэтому
задача №1.1 донести до Высшего руководства предприятия корректную постановку задачи выхода из кризиса
задача №1.2 реализовать план преобразований (получить физические правильную модель и процессы)
2.IT-шная проблематика
Автоматизирована в КИС неэффективная модель организации и управления предприятием "автоматизация хаоса"
Новую модель организации (она совершенно другая) на платформе старых IT решений либо не возможно реализовать, либо это дорогостоящие "танцы с бубнами" (это надо бы с вендорами-разработчиками исследовать, но они "в глухой защите" и ни на какие контакты не идут, потому что у них сейчас все прекрасно - деньги и заказы льются рекой, им что то у себя радикально менять "не досуг")
Поэтому
задача №2.1 Сделать корректную постановку задачи на преобразование КИС, которая будет способна автоматизировать новую целевую модель устройства и управления предприятием (с вендорами ли, со структурой предприятия по развитию КИС ли)
задача №2.2 Реализовать запланированные преобразования КИС (силами вендора или структурным подразделением Предприятия)
Резюме:
Правильный порядок работ по преобразованию:
1ый этап параллельная постановка задачи с небольшим сдвигом (1.1 и 2.1)
2ой этап параллельное управление преобразованиями (1.2 и 2.1)
Моих компетенций хватит на выполнение задач 1.1,1.2 и 2.1 (частично, полностью закрыть не могу) Сейчас прорабатываем эту задачу 2.1 с холдингом МТЗ (на уровне Постановка задачи и разработка прототипа). Для задачи 2.2 нужны IT партнеры (желательно их участие и в задаче 2.1). С поиском IT-партнера пока ведется работа.
Если Прикладная часть не выполнена, то бесполезно внедрять IT-шную (это "сладкая парочка", одно без другого не работает)
В смежном родственном посте свои слабые доказательства разместил, но понимаю, что нужна более развернутая аргументация - Вы правы, ее нужно будет подготовить
RuLean - это подход по комплексному преобразованию устройства промпредприятий (производственной системы, системы управления предприятием и взаимоотношениями с Поставщиками цепи поставок и Потребителями) с применением тех методологий, об отсутствии которых в IT продуктах я сетую (см. в смежном посте). Т.е. это не выдумка новых методологий, это подход к их комплексному развертыванию на предприятиях.
Я - прикладник. Моя работа и компетентность - с помощью вышеуказанных методологий получить экономический эффект на уровне компании. Я не ITшник - не являюсь разработчиком или агентом какой-либо IT разработки какого-либо вендора. Про 1С и SAP говорю только в связи с тем, что чаще всего именно эти системы (кроме самостоятельного зоопарка созданного ITшным отделом предприятия) встречаю. SАР - ушел. Остался лидер 1С и Ко. К ним ОДИНАКОВО отношусь и обращаюсь. Наезд у меня не на 1С, а на IT отрасль и методологическую устаревшую основу, которую все вендоры эксплуатируют!
Моя "война" в моей работе с Прикладным миром: оказывается, что те практические изменения, которые для радикального роста эффективности нужно осуществить на предприятии НЕ ВОЗМОЖНО реализовать/поддержать в действующих на предприятиях корпоративных информационных системах (КИС)! И получается, что предприятия попадают в неприятную вилку: чтобы повысить свою экономическую эффективность они должны сделать то, что убьет их действующую КИС (в смысле потребует ее радикальной переработки или замены на новую), на что предприятия не готовы (только что потратили десятки-сотни миллионов и кучу времени и сил и вот опять!?) или не знают как это преобразование КИС осуществить (вендоры им в этом не помогают, помочь не в силах). Т.к. здесь и сейчас очень много "власти" у действующих КИС (все управленческие и финансовые транзакции осуществляются через нее), то ее нельзя взять и выключить на какое-то время. Получается действующие КИС - стали тормозом прогресса. С этой задачей/проблемой я и пришел на ХАБР (поэтому строчу ТАКИЕ посты от лица Прикладного мира, которые воспринимаются здесь как "странные", нарушающие благостную гармонию и самомнение IT отрасли).
Если коротко/тезисно: наиболее востребованные Прикладным промышленным миром методологии:
Бережливое производство - управление производственными цепочками и цепями поставок как виртуальным вытягивающим конвейером;
ISO серии 9000 - построение системы управления и развития предприятием (и цепей поставок) подчиненной цели повышения степени удовлетворенности Потребителей + децентрализация выработки согласованных решений (процессный подход + PDCA)
ISO/TS 16949 (SPC) - управление качеством (стабильностью/воспроизводимостью) технологических процессов на основе предупреждения несоответствий (Control Plan. индексы воспроизводимости Ср, Срк)
ISO/TS 16949 (APQP) - параллельные разработка и постановка на производство новых изделий в цепях поставок при отсутствии "твердого" ТЗ (с этой стандартизированной в 1996 году методологии IT отрасль скомпилировала себе (я считаю не очень хорошо) AGILE)
в продуктах ERP, Управление предприятиями/холдингами (даю оценку как эксперт в вышеуказанных методологиях) либо:
Никак не реализованы
Реализованы в виде отдельных фрагментарных элементов, которые не способны по определению дать тот системный эффект, ради которых эти методологии были разработаны и применяются
Но более страшная с моей т.з. вещь - это системное не понимание, искажение назначения/смыслов или девальвация (отрицание полезности, прикладной значимости) этих методологий разработчиками и аналитиками ЭКО систем этих IT продуктов. Слишком долго IT отрасль сама себе была постановщиком задачи для разработки решений для Прикладного мира. Когда то такая роль была единственно возможной и правильной (с 60х годов прошлого века с появления возможности использования компьютеров в промышленности), но сейчас, увы для IT отрасли, Прикладной мир улетел вперед, а IT отрасль застряла в своем морально устаревшем видении/разработках для промышленности и снобистски не хочет разбираться/учиться/догонять Прикладной мир. Отсюда такое недопустимо огромное количество результатов "автоматизации хаоса", и сейчас IT отрасль идет семимильными шагами к "цифровизации хаоса", вооружившись в своей слепоте стратегией "Дохлой лошади".
Более подробно, постараюсь развернуть эти тезисы в публикации
PS Спасибо за интерес! Видимо разработчики ERP систем и систем управления предприятиями не особо на ХАБРе представлены, раз нет реакций на мой достаточно резкий пост?
Я отдаю себе отчет, что общаясь с Вами (огромное Вам спасибо за ответственное отношение к нашей беседе), я общаюсь не с "владельцем" ПСР!))) И вместе с тем, я посчитал нужным/важным именно Вам адресовать обсуждаемые вопросы. Попробую свои соображения "почему" я так считаю сформулировать:
Я среагировал на позиционирования смыслов и содержания ПСР, с которого Вы начали свою статью:
Именно такое позиционирование ПСР (на которое Вы опираетесь в своей статье) я считаю проблемой
Я вижу следующую негативную тенденцию: в ситуации, когда предприятия СПАСЕТ только смена парадигмы (не улучшения или прорывные решения (крупное улучшение в рамках текущей парадигмы), а изменить парадигму (в моей статье Вы могли увидеть, как много аспектов все сразу комплексно нужно поменять на противоположные, заменить одну систему совершенно другой)) предприятия совершают прямо противоположные действия все усиливая и усиливая власть и механизмы сохранения/совершенствования существующей системы, что только уменьшает вероятность/возможность выхода на постановку задачи РАДИКАЛЬНОЕ ПРЕОБРАЗОВАНИЕ!
Ответы в стиле "к пуговицам претензии есть?" - я отвечаю только за показатели ПСР, можно, конечно, привычно принять (я обычно только такие и слышу, т.к. та постановка задачи которую я поднимаю, увы, не имеет "хозяина" в действующих системах управления), но ведь именно эти "пуговицы"/благие намерения дорогу в АД вымащивают!
Это все размышления к моему вопросу: "когда улучшения - это ЗЛО" (аналогия про "Дохлую лошадь").
И я затеял с Вами разговор, чтобы Вы, как носитель/создатель этого сильного механизма "системы постоянных улучшений ПСР" осознавали, не только его сильные стороны (о чем была Ваша статья и с сильными сторонами я не воюю), но и опасные ограничения, когда работа на полную катушку этого механизма - это уже не благо, а тормоз в развитии предприятия.
В качестве резюме, актуальная глобальная методическая Проблема/Задача заключаются в том, как определять такие точки бифуркации для компании и как создать механизмы управления такими преобразованием в согласованной дружбе с компетенциями по постоянным улучшениям (сейчас, эти сотрудники и носители таких компетенций, де факто выступают как противники/враги задаче радикального преобразования). Ну и маленькая/локальная))) Проблема/Задача - что делать конкретно в ПСР?
Извините, если мучал Вас "не по адресу"! С наступающим Новым Годом!
Ваши декларации в стиле "не сомневайтесь, у нас все правильно" не могут служить доказательством, т.к. это не вопрос ВЕРЫ (в чудодейственную силу ПСР), а вопрос смыслов и механизмов (и я хочу разобраться, а не принять на веру)!
А Ваши ответы про обратную связь, культуру кайдзен, приоритеты "сверху-вниз",... лишь убеждают меня в обоснованности моих сомнений, т.к. нужные слова/аргументы Вы в который уже раз не приводите (значит в системе координат ПСР их нет или у них ничтожная роль, раз они не приходят вам в голову)!
Например, вы говорите о приоритетах в развитии ПСР спускаемых сверху-вниз, но это все инструменты, никак не связанные с задачей "перепланировки" (ее в принципе невозможно сделать через приоритеты и кайдзен, для ее осуществления нужны абсолютно другие инструменты, которые Вы в своих ответах как раз не упоминаете).
Все приоритеты ПСР - это направления повышения операционной эффективности в рамках существующей "планировки комнат" для решения задачи постоянного повышения "комфорта и удобства пользования текущей планировкой из 100 000 комнат". Т.е. это все инструменты работы в текущей планировке.
Мой же вопрос состоял в том, какие механизмы в ПСР есть для решения задач "перепланировки". Например мы придумали организацию деятельности, в которой вместо существующих 100 000 комнат с таким-то оснащением и функционалом, надо уйти в абсолютно новую организацию производства с 60 000 комнат, с принципиально другим оснащением и функционалом. Через кайдзены и приоритеты такая задача не решается, от слова СОВСЕМ!
А весь этот долгий диалог я затеял только из-за того, что считаю что устройство производственных предприятий РОСАТОМА надо не улучшать (методами и культурой кайдзен (терапия из витаминок и тренировок)), а радикально преобразовывать (методами директивного управления преобразованиями, для перехода в целевое состояние с другим организационным строением (нужна хирургия, вместо терапии)). Чуть подробнее эту мысль развернута https://habr.com/ru/articles/978502/
Факт_1. Предприятия (в абсолютной массе) не адекватно устроены и управляются - это корневая причина их экономических проблем и тенденции деградации (утраты рыночных позиций)
Факт_2. Как надо преобразовать устройство предприятия и систему управления на предприятии не знают (знали бы - давно поменялись бы). Поэтому это БОЛЬШАЯ МЕТОДИЧЕСКАЯ ГЛУПОСТЬ спрашивать у отдельных представителей предприятия (в рамках внедрения ERP), что они считают TO BE. Собранные таким образом "лоскутные одеяла" мнений TO BE от 40-100 сотрудников предприятия - это то же броуновское движение и сохранение неадекватности (возможно, даже ее усиление), а ни какое не TO BE, которое сделает предприятие адекватным/эффективным. Закономерный итог - проект неадекватного же устройства предприятия (тот же хаос, но с громким маркетинговым обманом TO BE)
Факт_3. ERP (от любого вендора) - это типовой (давно устаревший и не адекватный современным управленческим новациям, таким как LEAN, ISO серии 9000, ISO/TS 16949 (APQP, SPC,FMEA,MSA), ...) шаблон описания деятельности компаний (с моей т.з. не выдерживающий никакой критике). Т.е. автоматизируя деятельность предприятия по этим шаблонам В ПРИНЦИПЕ НЕ ВОЗМОЖНО вылечить не адекватность! Поэтому, ХАОС (обозванный TO BE) + ERP ШАБЛОН (принципиально устаревший) = АВТОМАТИЗИРОВАННЫЙ ХАОС (напрасно потраченные силы, время, деньги на решения, которые только усугубят печальную тенденцию деградации предприятия)
Эти 1,2,3 и нужно принять в качестве корневых причин для анализа рынка ERP и направлений его развития
ИМХО: IT отрасли нужно разработать совершенно новый ERP продукт (на базе LEAN, ISO серии 9000, ISO/TS 16949 (APQP, SPC,FMEA,MSA), ...) взамен неприемлемо устаревших ERP решений. Для этого разработчикам нужно изучить эти управленческие новации.
Мои мысли на этот счет https://habr.com/ru/articles/978502/
Факт_1. Предприятия (в абсолютной массе) не адекватно устроены и управляются - это корневая причина их экономических проблем и тенденции деградации (утраты рыночных позиций)
Факт_2. Как надо преобразовать устройство предприятия и систему управления на предприятии не знают (знали бы - давно поменялись бы). Поэтому это БОЛЬШАЯ МЕТОДИЧЕСКАЯ ГЛУПОСТЬ спрашивать у отдельных представителей предприятия (в рамках внедрения ERP), что они считают TO BE. Собранные таким образом "лоскутные одеяла" мнений TO BE от 40-100 сотрудников предприятия - это то же броуновское движение и сохранение неадекватности (возможно, даже ее усиление), а ни какое не TO BE, которое сделает предприятие адекватным/эффективным. Закономерный итог - проект неадекватного же устройства предприятия (тот же хаос, но с громким маркетинговым обманом TO BE)
Факт_3. ERP (от любого вендора) - это типовой (давно устаревший и не адекватный современным управленческим новациям, таким как LEAN, ISO серии 9000, ISO/TS 16949 (APQP, SPC,FMEA,MSA), ...) шаблон описания деятельности компаний (с моей т.з. не выдерживающий никакой критике). Т.е. автоматизируя деятельность предприятия по этим шаблонам В ПРИНЦИПЕ НЕ ВОЗМОЖНО вылечить не адекватность! Поэтому, ХАОС (обозванный TO BE) + ERP ШАБЛОН (принципиально устаревший) = АВТОМАТИЗИРОВАННЫЙ ХАОС (напрасно потраченные силы, время, деньги на решения, которые только усугубят печальную тенденцию деградации предприятия)
Эти 1,2,3 и нужно принять в качестве корневых причин для анализа рынка ERP и направлений его развития
Потихоньку продвигаемся))) Ок, следующий шаг, ПСР - это "квартира с сотней тысяч комнат", откуда работник из комнаты № 56 743 может узнать о планах на стены (какие можно улучшать, а какие нельзя)? Или он просто "кайзенит" на любые стены "не приходя в сознание"?
ЗЛО от улучшений на предприятии - напрасно потраченные время, деньги, силы
Давайте упростим задачу: когда улучшения в квартире - ЗЛО (напрасно потраченные время, силы, деньги)?
В том то и дело, что если ПСР занимается постоянными улучшениями и их много - это никакое не доказательство того, что ПСР не попало в ловушку стратегии "Дохлой лошади"!
"Дохлая лошадь" - это как раз про то, что Вы занимаетесь улучшениями, но того, что надо бросить как можно скорее, а не улучшать!
Попробуйте ответить на вопрос: в каких ситуациях улучшения - это ЗЛО?
К сожалению, всем нужна "справка о здоровье", а не "здоровье". Никто ради "здоровья" меняться не особо хочет, поэтому смыслы/идеи стандартов ISO серии 9000 не поняты и искажены/девальвированы. Подробнее мои мысли https://habr.com/ru/articles/978502/
А если модель производственной системы не адекватна современной бизнес-среде, нужно ли развивать культуру и бросать все силы на ее совершенствование? Очевидно же, что такие действия при условии "не адекватности" - это стратегическая ошибка (стратегия "Дохлой лошади" по индейцам Дакота во всей красе)! Т.к. тогда нужно бросить старую неадекватную модель (вместе с культурой постоянного ее совершенствования) и срочно разрабатывать новую адекватную (и только когда ее создадите, создавать для нее культуру постоянного совершенствования)!
Может имеет смысл проверить текущую ПСР на адекватность? (подробнее https://habr.com/ru/articles/978502/ )
Предприятие должно опираться на адекватную рынку бизнес-модель (решения по организации производства, системе управления и взаимодействию с Поставщиками и Потребителями). Если модель адекватная, то, очень вероятно, что для принятия правильных управленческих решений много данных и не понадобиться. И наоборот, если модель работы предприятия не адекватная, то ему не помогут и миллионы поступающих данных, как не управляй неадекватной моделью, ничего хорошего из этого не выйдет!
Поэтому тезис о том что для эффективного управления нужно очень много данных - очень спорный.
Действующие ERP решения основанные на функциональном подходе к управлению и прогнозах, как у автора:
Квартальный план (стратегический уровень)
Месячный план (тактический уровень)
Недельный план (оперативный уровень)
Суточный план (исполнительный уровень)
это сейчас вообще неприемлемые по эффективности решения (не адекватные современной бизнес-среде). Сейчас нужны вытягивающие гибкие процессные модели планирования и управления, чего в современных ERP решениях, увы, нет от слова СОВСЕМ (подробнее https://habr.com/ru/articles/978502/)
Переходить надо на решения, которые, увы, не поддерживается ни одним из перечисленных продуктов в публикации. Подробности раскрытия этого тезиса см. https://habr.com/ru/articles/978502/
К сожалению, этот тезис и, как следствие, последующие рассуждения на его основе - это ОШИБКА!
Главная цель и условие эффективного существования современных бизнес-систем - точно вовремя исполненный заказ Потребителя. "Точно вовремя" возможно обеспечить если в обещаниях клиенту по срокам учтены все работы по поддержанию работоспособности оборудования. А для этого все работы по обслуживанию оборудования должны выполняться как плановые (заранее известные) по модели, которая у Вас обозначена, как:
Сложность такого обслуживания связана с тем, что остановки производства на предписывающее обслуживание должны быть синхронизированы по производственной цепи.
Поэтому, вроде бы очевидный чемпион по абсолютным затратам подход "обслуживание оборудования по состоянию", оказывается неприемлемым с точки зрения бизнес-задач . Т.к. цель бизнеса не обеспечить минимальные затраты на обслуживание оборудования, а обеспечить выполнение точно вовремя заказов клиентов (именно это приносит деньги бизнесу), а для этого подходит (повторюсь) ТОЛЬКО подход Предписывающее обслуживание! Поэтому стратегию применения датчиков и интернета вещей надо подбирать/настраивать не под модель "обслуживание оборудования по состоянию"
ERP построенные на идее прогнозирования и подетального пооперационного планирования - категорически устарели и не соответствуют требованиям сегодняшнего времени. Сейчас нужны решения использующие вытягивающее (реагирующее) планирование на основе КАНБАН и управление производственными активами цепи поставок как виртуальным конвейером в ТАКТ. Это совершенно разные идеологические решения!
Вопрос автору: разрабатываемые Вами ERP обладают этой востребованной сейчас функциональностью?
ERP построенные на идее прогнозирования и подетального пооперационного планирования - категорически устарели и не соответствуют требованиям сегодняшнего времени. Сейчас нужны решения использующие вытягивающее (реагирующее) планирование на основе КАНБАН и управление производственными активами цепи поставок как виртуальным конвейером в ТАКТ. Это совершенно разные идеологические решения!
Вопрос автору: разрабатываемые Вами ERP обладают этой востребованной сейчас функциональностью?
Мучаюсь 2 вопросами, может автор ответит?
Почему в качестве инструмента для описания архитектуры предприятия используется не принятый в прикладном мире международный стандарт ISO серии 9000 (3 млн. организаций сертифицированы + неизвестное количество организаций, которые используют стандарт, но не сертифицируются), а не понятный этому миру (понятный только ITшникам) TOGAF?
Как осуществить соответствие (и кто его проведет) создаваемых описаний архитектур Организацией на ее языке ISO серии 9000 и созданный ITшниками на языке TOGAF?
Несмотря на то, что комментарий направлен не мне (не содержит вопросов к автору и не нуждается в моем ответе), а направлен на поиск единомышленников в абсолютном неприятии публикации (с великими людьми и не такое бывает) и критику бизнес-консультантов (почему то по мнению комментатора - это низшая степень компетенций в его личной иерархии), среагирую:
Краткое содержание, цели и выводы публикации (для тех, от кого оно ускользнуло):
Введение:
Проблемная область: Есть Клиенты-Покупатели - промышленные предприятия, есть IT Поставщики-Продавцы IT продуктов для управления промпредприятиями/холдингами (решения класса ERP). И автор (как эксперт от клиентов), обсуждает проблему неприемлемого качества этих IT продуктов, которое является следствием неприемлемого уровня знаний IT отрасли о своем Заказчике, которое в свою очередь, является следствием сложившегося неприемлемого стандарта взаимодействия IT отрасли со своими Заказчиками.
Цель публикации - объяснить IT отрасли, что происходит в Промышленности, показать, что то, что сейчас делает IT отрасль - неприемлемо, и призвать ее к преобразованиям (начать изучать знания, используемые сейчас в промышленности, установить корректное взаимодействие с Заказчиками, и как итог разработать нужные Потребителям IT продукты). Это разговор Заказчика с Исполнителем, на языке Заказчика
Глава 1.
Если Вы хотите корректно понять процессы происходящие в настоящее время в промышленности, то это стадия перехода из состояния "Можно работать как монополисты" (СПРОС > ПРЕДЛОЖЕНИЯ) в альтернативное состояние "Работать как монополисты НЕЛЬЗЯ" (ПРЕДЛОЖЕНИЕ > СПРОСА).
Глава 2.
Объясняется радикальная разница в ведении бизнеса и устройстве предприятий, когда ты можешь позволить себе работать как монополист, и для высококонкурентной среды (когда работать как монополист - гарантированная смерть предприятию). Это две различные АЛЬТЕРНАТИВНЫЕ системы решений (система ТРЕУГОЛЬНИКОВ и система КРУЖОЧКОВ)
Главный вывод Главы 1 и 2 с корректной постановкой задачи "Что происходит и что нужно делать?":
Глава 3.
В ней приведены мои оценки (как эксперта от промышленности) по текущей ситуации, с т.з. вышеописанной постановки задачи (их 9).
А теперь, в свою очередь, не могу не удержаться от удивления от позиции комментатора и оценок от сообщества ХАБРа:
Насколько надо быть ангажированным, чтобы не увидеть в статье ни одного смысла, ни одного вывода!?
Обычно, если что-то "НЕ ПОНЯТНО" в общении с КЛИЕНТОМ, то говорить КЛИЕНТУ "НИЧЕГО НЕ ПОНЯТНО" - это профессиональное самоубийство! Если ты хочешь быть полезным КЛИЕНТУ, сделай усилие, изучи его язык и проблематику, задавай уточняющие вопросы, НО РАЗБЕРИСЬ или не заявляй, что это твоя клиентская группа!? Устраивать же мне, как представителю ЗАКАЗЧИКОВ обструкцию, вместо попытки РАЗОБРАТЬСЯ - это верх какого-то СНОБИЗМА и ПРЕНЕБРЕЖЕНИЯ интересами КЛИЕНТА!?
Ваша позиция лишь утверждает меня в верности моей гипотезы об ОГРОМНОЙ проблеме в IT отрасли, которая так же мною сформулирована в Главе 2
У Вас на ХАБРе засилье экспертов от промышленности, что Вам не интересно со мной общаться (не видите в этом пользы - видите только ЗЛО) и Вы предпочитаете меня "слить" и заткнуть мне рот своими минусами!? Ни одного плюсика или благодарности за идеи и пищу для размышлений, только НЕГАТИВ!? Мои попытки общения и высказывания своих мыслей - для ХАБРа угроза что ли!? Здесь так принято бороться с инакомыслием!?
Я - консультант, да еще и преподаватель в ВШЭ, поэтому выбор стилистики ответа, по умолчанию, у меня соответствует моей профессиональной деформации))) Конкретизируйте вопрос (приземлите меня) - попробую ответить "по человечески")))
Есть, но это прецеденты (не только МТЗ, по моему резюме можно увидеть с кем подобная постановка задачи продвигалась (везде с разной пройденной дистанцией), но это единицы), а не система, поэтому продвижение (как я понял и в соответствии с Вашим опытом) - сложное/медленное. МТЗ - это прецедент, когда проблематика не соответствующей КИС выведена на уровень ключевых проблем, которые нужно комплексно решать и консультанты выступают как постановщики задачи целевой КИС.
Интересно! Поделитесь ссылкой, где я могу с Вашими идеями познакомиться (если не секрет)?
PS Опубликовал статью с аргументацией, как я это вижу и понимаю, в т.ч. по Вашей просьбе - можете с ней познакомиться https://habr.com/ru/articles/978502/
Моя т.з. на постановку задачи и ее решение:
Прикладная проблематика
Действующая на предприятии система решений (по организации производства, системе управления, взаимодействию с Поставщиками цепи Поставок и Потребителями, по подходам к управлению качеством и надежностью процессов/продукции, логистическим транзакциям и т.п....) находятся в гармонии (соответствуют и согласованы друг с другом), но дают неприемлемый по экономической эффективности результат и вводят предприятия в системный цикл деградации: рост оборотки при замедлении ее оборачиваемости, срыв контрактов, кассовые разрывы, ухудшение взаимоотношений с поставщиками (кризис не платежей), уменьшение возможностей по уровню зарплат (кадровые проблемы) и инвестиций на развитие). И такая ситуация - это системная проблема (верна для 95% компаний).
Выход из кризиса - это радикальное преобразование действующей системы решений (по перечисленным методологическим новациям) в масштабе предприятия/цепей поставок, который позволит в разы на порядки повысить экономическую эффективность и победить цикл деградации (войти в цикл роста)
Руководство/главные специалисты предприятия не корректно оценивают ситуацию и выбирают стратегию выхода из кризиса - предпочитают методами локальных улучшений повысить эффективность действующей системы решений (ищут легких путей, верят в старые решения). Но в текущей бизнес-среде - это стратегия "Дохлой лошади" (максимально возможный эффект - рост на уровне долей процентов/единиц процентов, а это категорически не достаточно, чтобы выйти из деградационного цикла)
Поэтому
задача №1.1 донести до Высшего руководства предприятия корректную постановку задачи выхода из кризиса
задача №1.2 реализовать план преобразований (получить физические правильную модель и процессы)
2.IT-шная проблематика
Автоматизирована в КИС неэффективная модель организации и управления предприятием "автоматизация хаоса"
Новую модель организации (она совершенно другая) на платформе старых IT решений либо не возможно реализовать, либо это дорогостоящие "танцы с бубнами" (это надо бы с вендорами-разработчиками исследовать, но они "в глухой защите" и ни на какие контакты не идут, потому что у них сейчас все прекрасно - деньги и заказы льются рекой, им что то у себя радикально менять "не досуг")
Поэтому
задача №2.1 Сделать корректную постановку задачи на преобразование КИС, которая будет способна автоматизировать новую целевую модель устройства и управления предприятием (с вендорами ли, со структурой предприятия по развитию КИС ли)
задача №2.2 Реализовать запланированные преобразования КИС (силами вендора или структурным подразделением Предприятия)
Резюме:
Правильный порядок работ по преобразованию:
1ый этап параллельная постановка задачи с небольшим сдвигом (1.1 и 2.1)
2ой этап параллельное управление преобразованиями (1.2 и 2.1)
Моих компетенций хватит на выполнение задач 1.1,1.2 и 2.1 (частично, полностью закрыть не могу) Сейчас прорабатываем эту задачу 2.1 с холдингом МТЗ (на уровне Постановка задачи и разработка прототипа). Для задачи 2.2 нужны IT партнеры (желательно их участие и в задаче 2.1). С поиском IT-партнера пока ведется работа.
Если Прикладная часть не выполнена, то бесполезно внедрять IT-шную (это "сладкая парочка", одно без другого не работает)
Не уверен, такой ли ответ Вы ожидали получить?
В смежном родственном посте свои слабые доказательства разместил, но понимаю, что нужна более развернутая аргументация - Вы правы, ее нужно будет подготовить
RuLean - это подход по комплексному преобразованию устройства промпредприятий (производственной системы, системы управления предприятием и взаимоотношениями с Поставщиками цепи поставок и Потребителями) с применением тех методологий, об отсутствии которых в IT продуктах я сетую (см. в смежном посте). Т.е. это не выдумка новых методологий, это подход к их комплексному развертыванию на предприятиях.
Я - прикладник. Моя работа и компетентность - с помощью вышеуказанных методологий получить экономический эффект на уровне компании. Я не ITшник - не являюсь разработчиком или агентом какой-либо IT разработки какого-либо вендора. Про 1С и SAP говорю только в связи с тем, что чаще всего именно эти системы (кроме самостоятельного зоопарка созданного ITшным отделом предприятия) встречаю. SАР - ушел. Остался лидер 1С и Ко. К ним ОДИНАКОВО отношусь и обращаюсь. Наезд у меня не на 1С, а на IT отрасль и методологическую устаревшую основу, которую все вендоры эксплуатируют!
Моя "война" в моей работе с Прикладным миром: оказывается, что те практические изменения, которые для радикального роста эффективности нужно осуществить на предприятии НЕ ВОЗМОЖНО реализовать/поддержать в действующих на предприятиях корпоративных информационных системах (КИС)! И получается, что предприятия попадают в неприятную вилку: чтобы повысить свою экономическую эффективность они должны сделать то, что убьет их действующую КИС (в смысле потребует ее радикальной переработки или замены на новую), на что предприятия не готовы (только что потратили десятки-сотни миллионов и кучу времени и сил и вот опять!?) или не знают как это преобразование КИС осуществить (вендоры им в этом не помогают, помочь не в силах). Т.к. здесь и сейчас очень много "власти" у действующих КИС (все управленческие и финансовые транзакции осуществляются через нее), то ее нельзя взять и выключить на какое-то время. Получается действующие КИС - стали тормозом прогресса. С этой задачей/проблемой я и пришел на ХАБР (поэтому строчу ТАКИЕ посты от лица Прикладного мира, которые воспринимаются здесь как "странные", нарушающие благостную гармонию и самомнение IT отрасли).
Если коротко/тезисно: наиболее востребованные Прикладным промышленным миром методологии:
Бережливое производство - управление производственными цепочками и цепями поставок как виртуальным вытягивающим конвейером;
ISO серии 9000 - построение системы управления и развития предприятием (и цепей поставок) подчиненной цели повышения степени удовлетворенности Потребителей + децентрализация выработки согласованных решений (процессный подход + PDCA)
ISO/TS 16949 (SPC) - управление качеством (стабильностью/воспроизводимостью) технологических процессов на основе предупреждения несоответствий (Control Plan. индексы воспроизводимости Ср, Срк)
ISO/TS 16949 (APQP) - параллельные разработка и постановка на производство новых изделий в цепях поставок при отсутствии "твердого" ТЗ (с этой стандартизированной в 1996 году методологии IT отрасль скомпилировала себе (я считаю не очень хорошо) AGILE)
в продуктах ERP, Управление предприятиями/холдингами (даю оценку как эксперт в вышеуказанных методологиях) либо:
Никак не реализованы
Реализованы в виде отдельных фрагментарных элементов, которые не способны по определению дать тот системный эффект, ради которых эти методологии были разработаны и применяются
Но более страшная с моей т.з. вещь - это системное не понимание, искажение назначения/смыслов или девальвация (отрицание полезности, прикладной значимости) этих методологий разработчиками и аналитиками ЭКО систем этих IT продуктов. Слишком долго IT отрасль сама себе была постановщиком задачи для разработки решений для Прикладного мира. Когда то такая роль была единственно возможной и правильной (с 60х годов прошлого века с появления возможности использования компьютеров в промышленности), но сейчас, увы для IT отрасли, Прикладной мир улетел вперед, а IT отрасль застряла в своем морально устаревшем видении/разработках для промышленности и снобистски не хочет разбираться/учиться/догонять Прикладной мир. Отсюда такое недопустимо огромное количество результатов "автоматизации хаоса", и сейчас IT отрасль идет семимильными шагами к "цифровизации хаоса", вооружившись в своей слепоте стратегией "Дохлой лошади".
Более подробно, постараюсь развернуть эти тезисы в публикации
PS Спасибо за интерес! Видимо разработчики ERP систем и систем управления предприятиями не особо на ХАБРе представлены, раз нет реакций на мой достаточно резкий пост?