Публичный флейм: Почему планирование - это зло.


8 года 8 мес. назад #34184 от Владимир Михейкин

Евгений Фролов пишет:
Владимир, по-моему, Вы многое за меня додумываете, хотя я такого вовсе не говорил. :)


Конечно додумываю, так как мне приходится переводить Ваши установки в свою систему координат: Вы в моей системе координат "говорить" не умеете:)

Евгений Фролов пишет: Одно могу сказать наверняка: в тех производствах, с которыми мне приходилось и ныне приходится иметь дело, я не разу не встречал случая, когда путем "лин-заклинаний" (а какой же начальник цеха в "гембе" не слыхал про 5S или SMED :) ) или с помощью увлекательных рассказов мастерам и рабочим про необходимость "снижения вариабильности" удавалось бы скорректировать срывающийся производственный план.

А Вам такие случаи известны? :) :) :)


Случаи "мартышка и очки", я думаю, встречаются, как с реализацией Lean, так и с реализацией IT проектов :) . Возможно, Вы обратили внимание, что здесь на LeanZone ведется достаточно жаркая дискуссия по поводу подходов и содержания Lean преобразований. Я нахожусь в лагере оппонентов пути "Иди в гемба, найди муда, сделай кайдзен, начни с 5С". Не эффективность такого подхода я не однократно наблюдал (при этом локальные эффекты могут быть очень значимыми).

Но я так же как и Вы по "эффективности" Lean инструментов, обладаю печальной статистикой по "эффективности" систем пооперационного подетального планирования: я их успешно работающих за свою 26-летнюю карьеру в консалтинге не встречал :( И это, как правило, не моя оценка, а оценка сотрудников самих предприятий (точность исполнения заказов на неприемлемом уровне, НЗП растет, планы начинают корректироваться с момента разработки, ...). Поэтому со спокойной совестью я могу вернуть Вам свою оценку, аналогичную Вашей "на предприятиях, которые я видел, IT решения по пооперационному подетальному планированию были "как мертвому - припарка" B)

Мои Lean проекты, как правило, оцениваются по результату (пока не сократилось время производства, не уменьшилось НЗП, не увеличилась пропускная способность производства, не повысилась до целевого значения точность производства, ... т.е. не получены экономические эффекты) проект, как правило, считается не выполненным и расплачиваться со мной не чем :). Т.е. критерием выполнения проекта является достижение целевого уровня эффективности.

Как я понимаю, ответственность поставщиков IT-решений совсем другая: в момент, когда клиент купил IT-решение, он принимает на себя всю ответственность за результат его применения у себя на предприятии. IT-Проект считается выполненным, когда IT решение установлено и функционирует. Степень изменения эффективности бизнеса, как правило, не является основным критерием выполнения IT проекта, поэтому примеров "купили, установили, лучше не стало" избыточно много.

Предлагаю вернуться к самолету и разнице в установках в отношении производства (расскажу Вам еще немного об альтернативной Вашей системе координат :) )?

Для того, чтобы выполнить Lean проект, приходится существенным образом менять расположение оборудования, технологические приемы выполнения операций, методы подготовки производства (включая логистику), иначе распределять производственный функционал между операционными и обеспечивающими службами и т.п. Это все действия, которые создают новые существенно возросшие возможности производства. Именно эти возможности позволяют реорганизовать производство в поток и реализовать новую идеологию оперативного планирование (вытягивание в потоке). Для достижения этого результата используются инструменты (Карта потока, выравнивание, SMED, TPM, 5S,...) которые Вы подвергаете обструкции. Т.е. логика преобразований следующая: нужно физически изменить возможности производства для реализации новой системы планирования. Т.е. в Lean проектах два горизонта улучшений: физическое повышение возможностей и переход на новую существенно более эффективную систему оперативного планирования. Поэтому Ваша аналогия про самолет противоестественна в изложенной парадигме: для того чтобы быстрее лететь к цели, нужно улучшить сам самолет и методы управления новыми возросшими возможностями.

Ваша же установка, как я ее понимаю: возможности производства фиксируются в состоянии "как есть", основной объект улучшений - устранение ошибок в планах использования существующих возможностей. Но такие IT-преобразования, ИМХО:

- обладают априори меньшей эффективностью, чем Lean-преобразования (разная по эффективности исходная база производственных возможностей: "как есть" vs "улучшенные возможности")

- в исходном состоянии "как есть" (дисбаланс мощностей, высокая вариабельность степени готовности и качества операций, ...), вероятность реализации любого плана минимальна. Повторю здесь свое соображение из соседней ветки:

ИМХО пара мыслей о «задаче планирования через нормы»:

Базой для планирования является «время производства». «Время производства» складывается из «времени обработки» и «времени ожиданий».

«Время обработки» - как условно-постоянная величина легко поддается оценке, и его, худо-бедно, привыкли/умеют измерять/нормировать.

«Время ожиданий», как функция от многих факторов с большой степенью неопределенности (таких как случайность заказов по объему, номенклатуре, времени поступления, уровня несоответствий, готовности производства, размера партий запуска и т.п.) – очень сложный объект для оценки (огромный диапазон изменчивости и вариативности состояний). Соотношение «времени обработки» и «времени производства» от 1:10 до 1:100 и больше, т.е. точность оценки «времени производства» определяется точностью оценки «времени ожиданий», которая оставляет желать лучшего. Для того, чтобы научиться нормировать «время ожиданий» с приемлемой для практического применения точностью, нужно придумать «подход», как это сделать:

• честно реактивно обсчитывать каждое уникальное состояние (пооперационное подетальное повременное планирование),
• выделять ключевой фактор (планирование через ограничение (ТОС)),
• уменьшать вариативность состояний и влияния вариабельности на производство (поточная организация производства и планирование в однородной нормированной среде (LEAN)),
• что-то еще («метод калибровки» от С. Питеркина , как вариант реактивной настройки под любое уникальное состояние)



С этих позиций, утверждение "такое-то IT решение превратит любой "махолет" в самолет, в котором задача экипажа будет сводится только к корректировкам на ветер" вызывает отторжение.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад #34185 от Александр Запорожцев

Андреас Штоль пишет: Но я-то вкладывал иной смысл! :)
Я этим словом (как мог) пытался выразить ОСОБУЮ, важнейшую роль одного компонента,его составляющей в общем интегральном качестве.

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

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад - 8 года 8 мес. назад #34188 от Андреас Штоль

Александр Запорожцев пишет: ... вы не только видите систему не только в операционном окружении, но и видите всю структуру системы и держите под контролем все элементы, а не сужаете систему до главного элемента

Отнюдь не сужаю. И не пытался. Это Вы так поняли. Даже на приведенной картинке я изобразил систему, которая состоит из нескольких элементов.

Александр Запорожцев пишет: ... считая что обеспечение ресурсами главного элемента обеспечит положительный эффект.

И так я не считаю. Совсем наоборот: скорее обозначенный элемент питает ресурсами (в данном случае данными о факте) все другие компоненты, а потому и является главным.
Вот нашел определение: Системообразующий - условное понятие для обозначения элемента системы, без которого она не может состояться;
Вот еще (навскидку): оп исываются системообразующие и вспомогательные компоненты .
И еще: Ленин «системообразующем элементом» в партийном строительстве считал газету. Это же не значит, что он выделял его в качестве единственного.
Впрочем он и "об одинаковой значимости" элементов говорил, считая, что каждая домохозяйка должна уметь управлять государством. Такой "равной значимости", оторванной от иерархической зависимости я не принимаю.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад #34208 от Александр Запорожцев

Андреас Штоль пишет: Вот нашел определение: Системообразующий - условное понятие для обозначения элемента системы, без которого она не может состояться

Я считаю это определение противоречащим определению системы.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад #34209 от Александр Запорожцев

Андреас Штоль пишет: Такой "равной значимости", оторванной от иерархической зависимости я не принимаю.

Иерархическая зависимость существует только в организационных системах. Эта иерархия построена на отношениях подчиненности нижестоящих элементов вышестоящим. В технических системах отношения между вышестоящим элементом и нижестоящими основаны на отношениях целое - часть.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад - 8 года 8 мес. назад #34210 от Михаил Шустер
Александр, это вы сейчас погорячились. Иерархичность, структура-одно из свойств системы. Об этом здесь все сказали разными словами, даже небольшой спорчик вышел об одном и том же. Слово "оргструктура" более конкретно, тем не менее очень правильное: это один из взглядов на организацию, не единственный. Структура продаж, структура изделия, структура документации...
Возможно, я просто не понял, что вы сказали

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад #34225 от Андреас Штоль

Александр Запорожцев пишет:

Андреас Штоль пишет: Вот нашел определение: Системообразующий - условное понятие для обозначения элемента системы, без которого она не может состояться

Я считаю это определение противоречащим определению системы.

Определений системы - десятки. Кроме того я специально выделил слова, которые подчеркивали мою мысль.
Вы имеете право придерживаться определенных (но системных) позиций.
Например, вы говорите: "Моим представлениям о системе, системном анализе базируются на концепции (и тут вы называете автора, которому и будете последовательно придерживаться). Если же Вы что-то "берете" у одного, что-то у другого и т.д., формируя при этом собственную концепцию, то тогда четко сформулиуйте ее, вынесете на обсуждение научной общественности, защитите и уже только потом можете оперировать ею как авторской.
Мои представления о системах базируются:
1) если говорить о педагогических системах - на теории функционирования пед. систем Н.В.Кузминой
2) если говорить о тех. системах - то на работах Половинкина А.И.,Одрина В.М., Альтшуллера Г.С.
Готов на них ссылаться с указанием литературы.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад #34230 от Андреас Штоль

Александр Запорожцев пишет:

Андреас Штоль пишет: Такой "равной значимости", оторванной от иерархической зависимости я не принимаю.

Иерархическая зависимость существует только в организационных системах. Эта иерархия построена на отношениях подчиненности нижестоящих элементов вышестоящим. В технических системах отношения между вышестоящим элементом и нижестоящими основаны на отношениях целое - часть.

"Все смешалось в доме Облонских"...
У Вас удивительным образом в одну кучу свалились представления о компонентном, структурном и функциональныз подходах.
1)компонентный подход (автор называл его поэлементным анализом), был предложен в нач. 50-х готов Ю.М.Соболевым, который еще тогда рекомендовал разделять элементы системы на основные и вспомогательные ()его работа Консруктор и экономика: ФСА для конструктора
2)структурный подход рассматривает в частности вопросы иерархии (в общем смысле расположение в определенном порядке) может наблюдаться в самых различных системах, включая технические. Требуется заметить, что не все структуры иерархичны - например, т.н. ретикулярные структуры.
3) функциональный подход (предложенный в 40-х годах сотрудником фирмы Дженерал моторс Л.Майлзом) . рассматривает системы с точки зрения функции (также выделяя в системах основные, вспомогательные и второстепенны функции). Вспомните, как проводится ФСА.
4)отношения в технических системах далеко не ограничиваются отношениями части и целого.
Есть и другие отношения и связи. Здесь можно говорить о "энергетической проводимости систем", об информационных потоках, преобразованиях и т.д. Вспомните телевизор (что на входе и что на выходе, какие были преобразования)

Я, пожалуй, не буду больше добавлять комментарии в ваши "системные представления". Вы - педагог со стажем. Вы привыкли УЧИТЬ. Значит, будете "намертво" стоять на своей позиции. Если я Вам показался слишком категоричным - простите великодушно. :)
Спасибо сказали: Михаил Шустер

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад #34238 от Александр Запорожцев

Михаил Шустер пишет: Александр, это вы сейчас погорячились.

Погорячился? Скорей всего так и есть. Терминологические споры - самые бессмысленные.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.


8 года 8 мес. назад - 8 года 8 мес. назад #34241 от Александр Филонов

Александр Запорожцев пишет: Погорячился? Скорей всего так и есть. Терминологические споры - самые бессмысленные.


Отнюдь. :) Читаем Деминга. Все начинается с "операциональных определений". Нет согласия в определениях - нет смысла.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Работает на Kunena форум