Публичный флейм: Почему планирование - это зло.
- Владимир Михейкин
- Не в сети
- Пользователь заблокирован
- Сообщений: 567
- Спасибо получено: 40
Евгений Фролов пишет:
Владимир, по-моему, Вы многое за меня додумываете, хотя я такого вовсе не говорил.
Конечно додумываю, так как мне приходится переводить Ваши установки в свою систему координат: Вы в моей системе координат "говорить" не умеете
Евгений Фролов пишет: Одно могу сказать наверняка: в тех производствах, с которыми мне приходилось и ныне приходится иметь дело, я не разу не встречал случая, когда путем "лин-заклинаний" (а какой же начальник цеха в "гембе" не слыхал про 5S или SMED ) или с помощью увлекательных рассказов мастерам и рабочим про необходимость "снижения вариабильности" удавалось бы скорректировать срывающийся производственный план.
А Вам такие случаи известны?
Случаи "мартышка и очки", я думаю, встречаются, как с реализацией Lean, так и с реализацией IT проектов . Возможно, Вы обратили внимание, что здесь на LeanZone ведется достаточно жаркая дискуссия по поводу подходов и содержания Lean преобразований. Я нахожусь в лагере оппонентов пути "Иди в гемба, найди муда, сделай кайдзен, начни с 5С". Не эффективность такого подхода я не однократно наблюдал (при этом локальные эффекты могут быть очень значимыми).
Но я так же как и Вы по "эффективности" Lean инструментов, обладаю печальной статистикой по "эффективности" систем пооперационного подетального планирования: я их успешно работающих за свою 26-летнюю карьеру в консалтинге не встречал И это, как правило, не моя оценка, а оценка сотрудников самих предприятий (точность исполнения заказов на неприемлемом уровне, НЗП растет, планы начинают корректироваться с момента разработки, ...). Поэтому со спокойной совестью я могу вернуть Вам свою оценку, аналогичную Вашей "на предприятиях, которые я видел, IT решения по пооперационному подетальному планированию были "как мертвому - припарка"
Мои Lean проекты, как правило, оцениваются по результату (пока не сократилось время производства, не уменьшилось НЗП, не увеличилась пропускная способность производства, не повысилась до целевого значения точность производства, ... т.е. не получены экономические эффекты) проект, как правило, считается не выполненным и расплачиваться со мной не чем . Т.е. критерием выполнения проекта является достижение целевого уровня эффективности.
Как я понимаю, ответственность поставщиков IT-решений совсем другая: в момент, когда клиент купил IT-решение, он принимает на себя всю ответственность за результат его применения у себя на предприятии. IT-Проект считается выполненным, когда IT решение установлено и функционирует. Степень изменения эффективности бизнеса, как правило, не является основным критерием выполнения IT проекта, поэтому примеров "купили, установили, лучше не стало" избыточно много.
Предлагаю вернуться к самолету и разнице в установках в отношении производства (расскажу Вам еще немного об альтернативной Вашей системе координат )?
Для того, чтобы выполнить Lean проект, приходится существенным образом менять расположение оборудования, технологические приемы выполнения операций, методы подготовки производства (включая логистику), иначе распределять производственный функционал между операционными и обеспечивающими службами и т.п. Это все действия, которые создают новые существенно возросшие возможности производства. Именно эти возможности позволяют реорганизовать производство в поток и реализовать новую идеологию оперативного планирование (вытягивание в потоке). Для достижения этого результата используются инструменты (Карта потока, выравнивание, SMED, TPM, 5S,...) которые Вы подвергаете обструкции. Т.е. логика преобразований следующая: нужно физически изменить возможности производства для реализации новой системы планирования. Т.е. в Lean проектах два горизонта улучшений: физическое повышение возможностей и переход на новую существенно более эффективную систему оперативного планирования. Поэтому Ваша аналогия про самолет противоестественна в изложенной парадигме: для того чтобы быстрее лететь к цели, нужно улучшить сам самолет и методы управления новыми возросшими возможностями.
Ваша же установка, как я ее понимаю: возможности производства фиксируются в состоянии "как есть", основной объект улучшений - устранение ошибок в планах использования существующих возможностей. Но такие IT-преобразования, ИМХО:
- обладают априори меньшей эффективностью, чем Lean-преобразования (разная по эффективности исходная база производственных возможностей: "как есть" vs "улучшенные возможности")
- в исходном состоянии "как есть" (дисбаланс мощностей, высокая вариабельность степени готовности и качества операций, ...), вероятность реализации любого плана минимальна. Повторю здесь свое соображение из соседней ветки:
ИМХО пара мыслей о «задаче планирования через нормы»:
Базой для планирования является «время производства». «Время производства» складывается из «времени обработки» и «времени ожиданий».
«Время обработки» - как условно-постоянная величина легко поддается оценке, и его, худо-бедно, привыкли/умеют измерять/нормировать.
«Время ожиданий», как функция от многих факторов с большой степенью неопределенности (таких как случайность заказов по объему, номенклатуре, времени поступления, уровня несоответствий, готовности производства, размера партий запуска и т.п.) – очень сложный объект для оценки (огромный диапазон изменчивости и вариативности состояний). Соотношение «времени обработки» и «времени производства» от 1:10 до 1:100 и больше, т.е. точность оценки «времени производства» определяется точностью оценки «времени ожиданий», которая оставляет желать лучшего. Для того, чтобы научиться нормировать «время ожиданий» с приемлемой для практического применения точностью, нужно придумать «подход», как это сделать:
• честно реактивно обсчитывать каждое уникальное состояние (пооперационное подетальное повременное планирование),
• выделять ключевой фактор (планирование через ограничение (ТОС)),
• уменьшать вариативность состояний и влияния вариабельности на производство (поточная организация производства и планирование в однородной нормированной среде (LEAN)),
• что-то еще («метод калибровки» от С. Питеркина , как вариант реактивной настройки под любое уникальное состояние)
С этих позиций, утверждение "такое-то IT решение превратит любой "махолет" в самолет, в котором задача экипажа будет сводится только к корректировкам на ветер" вызывает отторжение.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5591
- Спасибо получено: 596
Именно так мы вас и поняли, именно против этой точки зрения и выступаем. По определению системы - нет там системообразующих элементов. Выделяя такой элемент, вы перестаете обращать внимание к остальным элементам и, неизменно, система рассыпается. Системное мышление основано на том, что вы не только видите систему не только в операционном окружении, но и видите всю структуру системы и держите под контролем все элементы, а не сужаете систему до главного элемента и считая что обеспечение ресурсами главного элемента обеспечит положительный эффект.Андреас Штоль пишет: Но я-то вкладывал иной смысл!
Я этим словом (как мог) пытался выразить ОСОБУЮ, важнейшую роль одного компонента,его составляющей в общем интегральном качестве.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Андреас Штоль
- Не в сети
- Давно я тут
- Сообщений: 420
- Спасибо получено: 98
Отнюдь не сужаю. И не пытался. Это Вы так поняли. Даже на приведенной картинке я изобразил систему, которая состоит из нескольких элементов.Александр Запорожцев пишет: ... вы не только видите систему не только в операционном окружении, но и видите всю структуру системы и держите под контролем все элементы, а не сужаете систему до главного элемента
И так я не считаю. Совсем наоборот: скорее обозначенный элемент питает ресурсами (в данном случае данными о факте) все другие компоненты, а потому и является главным.Александр Запорожцев пишет: ... считая что обеспечение ресурсами главного элемента обеспечит положительный эффект.
Вот нашел определение: Системообразующий - условное понятие для обозначения элемента системы, без которого она не может состояться;
Вот еще (навскидку): оп исываются системообразующие и вспомогательные компоненты .
И еще: Ленин «системообразующем элементом» в партийном строительстве считал газету. Это же не значит, что он выделял его в качестве единственного.
Впрочем он и "об одинаковой значимости" элементов говорил, считая, что каждая домохозяйка должна уметь управлять государством. Такой "равной значимости", оторванной от иерархической зависимости я не принимаю.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5591
- Спасибо получено: 596
Я считаю это определение противоречащим определению системы.Андреас Штоль пишет: Вот нашел определение: Системообразующий - условное понятие для обозначения элемента системы, без которого она не может состояться
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5591
- Спасибо получено: 596
Иерархическая зависимость существует только в организационных системах. Эта иерархия построена на отношениях подчиненности нижестоящих элементов вышестоящим. В технических системах отношения между вышестоящим элементом и нижестоящими основаны на отношениях целое - часть.Андреас Штоль пишет: Такой "равной значимости", оторванной от иерархической зависимости я не принимаю.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Михаил Шустер
- Не в сети
- Живу я здесь
- Сообщений: 1209
- Спасибо получено: 260
Возможно, я просто не понял, что вы сказали
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Андреас Штоль
- Не в сети
- Давно я тут
- Сообщений: 420
- Спасибо получено: 98
Определений системы - десятки. Кроме того я специально выделил слова, которые подчеркивали мою мысль.Александр Запорожцев пишет:
Я считаю это определение противоречащим определению системы.Андреас Штоль пишет: Вот нашел определение: Системообразующий - условное понятие для обозначения элемента системы, без которого она не может состояться
Вы имеете право придерживаться определенных (но системных) позиций.
Например, вы говорите: "Моим представлениям о системе, системном анализе базируются на концепции (и тут вы называете автора, которому и будете последовательно придерживаться). Если же Вы что-то "берете" у одного, что-то у другого и т.д., формируя при этом собственную концепцию, то тогда четко сформулиуйте ее, вынесете на обсуждение научной общественности, защитите и уже только потом можете оперировать ею как авторской.
Мои представления о системах базируются:
1) если говорить о педагогических системах - на теории функционирования пед. систем Н.В.Кузминой
2) если говорить о тех. системах - то на работах Половинкина А.И.,Одрина В.М., Альтшуллера Г.С.
Готов на них ссылаться с указанием литературы.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Андреас Штоль
- Не в сети
- Давно я тут
- Сообщений: 420
- Спасибо получено: 98
"Все смешалось в доме Облонских"...Александр Запорожцев пишет:
Иерархическая зависимость существует только в организационных системах. Эта иерархия построена на отношениях подчиненности нижестоящих элементов вышестоящим. В технических системах отношения между вышестоящим элементом и нижестоящими основаны на отношениях целое - часть.Андреас Штоль пишет: Такой "равной значимости", оторванной от иерархической зависимости я не принимаю.
У Вас удивительным образом в одну кучу свалились представления о компонентном, структурном и функциональныз подходах.
1)компонентный подход (автор называл его поэлементным анализом), был предложен в нач. 50-х готов Ю.М.Соболевым, который еще тогда рекомендовал разделять элементы системы на основные и вспомогательные ()его работа Консруктор и экономика: ФСА для конструктора
2)структурный подход рассматривает в частности вопросы иерархии (в общем смысле расположение в определенном порядке) может наблюдаться в самых различных системах, включая технические. Требуется заметить, что не все структуры иерархичны - например, т.н. ретикулярные структуры.
3) функциональный подход (предложенный в 40-х годах сотрудником фирмы Дженерал моторс Л.Майлзом) . рассматривает системы с точки зрения функции (также выделяя в системах основные, вспомогательные и второстепенны функции). Вспомните, как проводится ФСА.
4)отношения в технических системах далеко не ограничиваются отношениями части и целого.
Есть и другие отношения и связи. Здесь можно говорить о "энергетической проводимости систем", об информационных потоках, преобразованиях и т.д. Вспомните телевизор (что на входе и что на выходе, какие были преобразования)
Я, пожалуй, не буду больше добавлять комментарии в ваши "системные представления". Вы - педагог со стажем. Вы привыкли УЧИТЬ. Значит, будете "намертво" стоять на своей позиции. Если я Вам показался слишком категоричным - простите великодушно.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Запорожцев
- Не в сети
- Живу я здесь
- Сообщений: 5591
- Спасибо получено: 596
Погорячился? Скорей всего так и есть. Терминологические споры - самые бессмысленные.Михаил Шустер пишет: Александр, это вы сейчас погорячились.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Александр Филонов
- Не в сети
- Живу я здесь
- Сообщений: 6616
- Спасибо получено: 714
Александр Запорожцев пишет: Погорячился? Скорей всего так и есть. Терминологические споры - самые бессмысленные.
Отнюдь. Читаем Деминга. Все начинается с "операциональных определений". Нет согласия в определениях - нет смысла.
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
- Главная
- Форум
- Форум LeanZone.ru
- Общий
- Публичный флейм: Почему планирование - это зло.