Борис Кондрабаев пишет: Любое внедрение легче происходит, когда самостоятельные и самодостаточные люди понимают, что оно делает их работу более простой, легкой и комфортной. Этот клиенто-ориентированный принцип лежит в основе бережногоотношения к людям и процессам.
Борис, зачем здесь стоит слово бережного? - Это относится к теме Бережливое производство?
О чём статья? Японские методы, философия или их западная интерпретация - Lean Manufacturing имеет слабое отношение к тому, о чём говорят авторы Scrum, который продвигается под заимствованным названием Agile. Заимствованными являются и японские термины, в которые они вкладывают другое содержание.
Авторы Scrum - это глубоко погружённые в программирование специалисты, которые "вынырнули" на поверхность делового управления и пытаются сказать, что узкоспециализированные методы годятся для управления, трансформации большой компании. Для стартапа, небольшой команды это где-то работает, а для большой компании нужны другие методы, в том числе Lean Manufacturing. Но это совершенно другой подход )))
Борис Кондрабаев пишет: Кайдзен по своему определению это не четкая инструкция, а гибкая система, основанная на философии перемен и каждый раз изменяющая новой шлифовкой традиции, исходя из требований текущей ситуации. Тойти Оно, в своих воспоминаниях сам удивляется как это ему удалось изменить коллективное принятие изменения традиций/технологий и с какими трудностями ему пришлось столкнуться.
Борис, Кайздзен у японцев - это одна сторона медали, но он следует вслед за Кайрё (Kairyo) и они сменяют друг друга. Кайрё в нашем понимании - это Реинжиниринг компании. Вся японская тематика в данной теме "трансформации" компаний ))) - это законспированный восточный антураж, для продвижения, придания теме смысла, которого в ней на самом деле нет. Где-то, что-то задевает краем.
Давайте представим человека, который всю жизнь занимался программированием. Что он знает о японских методах или их западной интерпретации? Можно представить, что просто что-то где-то слышал ))) - это видно по топорному заимствованию части терминологии.
И не надо делать из программиста Гуру в деловом управлении, способным трансформировать большую компанию ))) - авторы Scrum и большинство новоиспечённых специалистов по "трансформации компаний" пришли именно из области программирования и связанных с этим областей деятельности - тестирование, внедрение программных продуктов, постановщики задач программистам и т.п ))) И как уже выше цитировалось от одного из первых авторов по этой теме "трансформаций" на этом ресурсе:
Дайте я тут немного поясню, под термином Kanban я все таки использую не канбан из TPS (Lean Manufacturing) а вот это: http://leankanban.com/project/wkanban/(пощелкайте там по ссылкам слева)Тут у создателей этого подхода постоянная путаница идет из-за того, что они переиспользовали слово (проклятый маркетинг)
Борис, зачем здесь стоит слово бережного? - Это относится к теме Бережливое производство?
О чём статья? Японские методы, философия или их западная интерпретация - Lean Manufacturing имеет слабое отношение к тому, о чём говорят авторы Scrum, который продвигается под заимствованным названием Agile. Заимствованными являются и японские термины, в которые они вкладывают другое содержание.
Авторы Scrum - это глубоко погружённые в программирование специалисты, которые "вынырнули" на поверхность делового управления и пытаются сказать, что узкоспециализированные методы годятся для управления, трансформации большой компании. Для стартапа, небольшой команды это где-то работает, а для большой компании нужны другие методы, в том числе Lean Manufacturing. Но это совершенно другой подход )))
Андрей, я ввел термин бережное вместо бережливое потому что он проще отражает смысл отношений, на которых основывается бережливое производство(БП).
Я понимаю, что авторы статьи могут подразумевать что то свое. Примерно об этом же писал Деминг, что компании вывешивают лозунги о том, что занимаются БП, но наполняют его совсем другим содержанием и следуют совсем другим курсом. Вероятно это же самое может происходить с Agile. Но именно в манифесте Agile описаны ценности, которые просты в понимании и следуя которым компании могут развиваться. Если руководители компаний будут придерживаться этих ценностей, то они с большей вероятностью смогут фокусировать и направлять сотрудников на решение общих задач.
Я не знаю, смогут ли авторы статьи трансформировать деятельность большой компании? В моем понимании БП надо начинать со стартапа. А в деятельности больших компаний можно делать методами и подходами непрерывные изменения. Сразу станет видно способны ли специалисты производить изменения. Способны ли руководители и специалисты больших компаний следовать изменениям. Ситуации бывают разные и нельзя заранее предсказать исход ситуации, в которой каждый влияет на каждого, как явно, так и скрытно.
Борис Кондрабаев пишет: Кайдзен по своему определению это не четкая инструкция, а гибкая система, основанная на философии перемен и каждый раз изменяющая новой шлифовкой традиции, исходя из требований текущей ситуации. Тойти Оно, в своих воспоминаниях сам удивляется как это ему удалось изменить коллективное принятие изменения традиций/технологий и с какими трудностями ему пришлось столкнуться.
Борис, Кайздзен у японцев - это одна сторона медали, но он следует вслед за Кайрё (Kairyo) и они сменяют друг друга. Кайрё в нашем понимании - это Реинжиниринг компании. Вся японская тематика в данной теме "трансформации" компаний ))) - это законспированный восточный антураж, для продвижения, придания теме смысла, которого в ней на самом деле нет. Где-то, что-то задевает краем.
Давайте представим человека, который всю жизнь занимался программированием. Что он знает о японских методах или их западной интерпретации? Можно представить, что просто что-то где-то слышал ))) - это видно по топорному заимствованию части терминологии.
И не надо делать из программиста Гуру в деловом управлении, способным трансформировать большую компанию ))) - авторы Scrum и большинство новоиспечённых специалистов по "трансформации компаний" пришли именно из области программирования и связанных с этим областей деятельности - тестирование, внедрение программных продуктов, постановщики задач программистам и т.п ))) И как уже выше цитировалось от одного из первых авторов по этой теме "трансформаций" на этом ресурсе:
Дайте я тут немного поясню, под термином Kanban я все таки использую не канбан из TPS (Lean Manufacturing) а вот это: http://leankanban.com/project/wkanban/(пощелкайте там по ссылкам слева)Тут у создателей этого подхода постоянная путаница идет из-за того, что они переиспользовали слово (проклятый маркетинг)
Андрей, каждый из нас имеет свое понимание как терминологии, так и ситуации. Если мы займемся изучением того, что мы понимаем и как понимаем, то на это может уйти много времени. Это концептуальное понимание может послужить лишь основой для взаимопонимания. И я даже не понимая Вас в отдельных деталях/терминах, на каком то уровне знаю и чувствую о чем Вы говорите. Конструктивный разговор возможен только в контексте реальной текущей ситуации. Именно в реальной ситуации лучше всего могут проявиться наши разные взгляды и пройденный опыт на неё. Обсуждая это в уважительном русле можно найти такие решения, на которые не способен ни один из нас по отдельности. Можете называть этот менеджмент/взаимодействие как хотите. Я его для себя определил, как "управление знаниями".
Отрывок из книги издательства "Миф" одной очень симпатичной девушки:
Не кормите зверя
В сфере IT работают по Agile. Слово переводится как «проворный», «шустрый». Суть в том, чтобы делить путь к большой цели — на короткие отрезки. В жизни можно и нужно делать так же. Экспериментировать и прислушиваться к себе. Нравится? Продолжайте. Нет? Меняйте вектор.
Так вы минимизируете искушения и экономите силу воли — еще пригодится.
Простой пример. Хочется приготовить полезный завтрак, но раковина забита грязной посудой. Не воодушевляет. И вот вы уже жуете хот-дог. Упс. Поступайте умнее — готовьтесь с вечера: помойте посуду, разложите продукты, поставьте на стол любимую тарелку. И так действуйте во всем.
Борис Кондрабаев пишет: Денис, Кайдзен по своему определению это не четкая инструкция, а гибкая система, основанная на философии перемен и каждый раз изменяющая новой шлифовкой традиции, исходя из требований текущей ситуации.
Борис, поправьте, если не так, но по этапам:
- Есть утвержденная инструкция, по которой все работают (утвержденное правило).
- Инициируется изменение/дополнение - проводится оценка/расчеты, локальная апробация, тестирование...
- Согласование и утверждение изменений
- Внедрение
- Обучение
ИТОГ:
- Есть НОВАЯ утвержденная инструкция, по которой все работают (утвержденное правило).
Таким образом, каждый сотрудник жестко контролируется, согласно сегодняшней инструкции и до утверждения/обучения по НОВОЙ, все отклонения считаются браком.
Лично для меня, есть следующее понимание:
"Гибкая система снаружи, очень жесткая изнутри" - без утвержденной изменении системы, любое творчество - ПРЕСТУПЛЕНИЕ.
+4100Виталий ЕлиферовМенеджер, Москва
Борис Кондрабаев пишет: Виталий, то что Вы называете в данном случае воспитанием, в моем понимании это технологии и бизнес-процессы, которые можно и нужно внедрять. Любое внедрение легче происходит, когда самостоятельные и самодостаточные люди понимают, что оно делает их работу более простой, легкой и комфортной.
Борис, я написал именно ВОСПИТАНИЕ, как способы и методы применения "мягкой" неформализуемой силы, для достижения поставленных задач. К технологиям и бизнес-процессам это не имеет никакого отношения. Мне приходилось руководить большими командам разработчиков, в том числе и комплексными (от разных компаний и вендоров).
Если Вы можете переложить в технологию и бизнес-процессы форматы общения разработчиков, неформальную поддержку соседа по команде, готовность отступить от своего "Я знаю лучше и ничего у себя менять не буду!" - это заявка на Нобелевскую премию. Даже Дмитрий Новиков в своих трудах по алгоритмизации трудовых отношений не смог этого сделать.
Борис Кондрабаев пишет: А в деятельности больших компаний можно делать методами и подходами непрерывные изменения
Денис Перевезнов пишет: Борис, поправьте, если не так, но по этапам: ...
Борису удалось перевести обсуждение статьи на совершенно другую тему и даже расщепить её ... )))
Всё что происходит в Scrum относится к небольшим командам, и даже уже создание такой команды - это Реинжиниринг. Небольшие и непрерывные изменения - это тоже натяжка - не та песня в случае с использованием Scrum - в такой команде каждый день, каждый спринт может поставить всё с ног на голову, и даже привести к смене целей проекта, изменению состава команды и пр. Это максимальная нестабильность во всём.
Погружать в такое "море ужаса" всю компанию будет безумием для руководителя. А борьба за чистоту методов некоторых апологетов может перекрыть всю пользу от этих методов работы ((( Определённый период в Nokia со своим видением Scrum тому пример.
Денис Перевезнов пишет: Борис, поправьте, если не так, но по этапам:- Есть утвержденная инструкция, по которой все работают (утвержденное правило).- Инициируется изменение/дополнение - проводится оценка/расчеты, локальная апробация, тестирование...- Согласование и утверждение изменений- Внедрение- ОбучениеИТОГ:- Есть НОВАЯ утвержденная инструкция, по которой все работают (утвержденное правило).Таким образом, каждый сотрудник жестко контролируется, согласно сегодняшней инструкции и до утверждения/обучения по НОВОЙ, все отклонения считаются браком.Лично для меня, есть следующее понимание:"Гибкая система снаружи, очень жесткая изнутри" - без утвержденной изменении системы, любое творчество - ПРЕСТУПЛЕНИЕ.
Начну с конца. Без жесткости невозможно постоянство качества. Поэтому в процессе производства нужны стандарты и инструкции, обеспечивающие постоянство качества "изделия", в том числе новыми улучшенными инструкциями. Здесь можно наблюдать определенную жесткость исполнения. Но сами ситуации, связанные с процессом производства непредсказуемы и здесь нужна определенная гибкость. Которой хорошо подходит "канбан бережливого производства".
Есть процессы подготовки производства, включая выбор имеющегося на рынке спроса и ниши, а также НИОКР/проекты. Им хорошо подходит дизайн-менеджмент(дизайн-мышление), Agile(какая точно часть вызывает полемику - поэтому привожу в целом).
В случае, когда требуется развитие компании, проекта можно "погрузившись в ситуацию" определить ограничения. Выбрать из них ключевое или те, на которые можно очень просто и быстро воздействовать. Поставить исполнителю или "кружку качества" задачу на решение. То есть предоставить им возможность проявить инициативу и возможность добиться личных достижений в решение актуальной для компании или проекта задачи.
Специалист по улучшениям стандартов/инструкций опирается на три показателя, которые нужно исследовать, чтобы увеличить скорость, не повлияв на качество или улучшить качество не теряя в производительности. Это потери, несогласованность взаимодействий и нецелесообразность выполнения определенных действий. Эти исследования универсальны для управления. Они могут быть использованы: в производстве, в исследованиях, проектах, военных компаниях и правительственных структурах и т.д.
Например, рассмотрим потери при механической обработке металла. Технолог написал технологию/инструкцию как нужно делать. При этом можно иметь ввиду, что он заложил определенный процент запаса. Также можно иметь ввиду, что появились новые инструменты, способные обрабатывать производительнее и не в ущерб качествам обрабатываемой поверхности. Появились высокоскоростные шпинделя, позволяющие обрабатывать уже закаленные стали, не нанося им температурных воздействий, так как вся температура уходит в стружку, которая при этом сгорает. То есть можно находить возможности для изменения технологий. Даже малые изменения очень сильно влияют на производительность(закон Парето).
Потери при простоях оборудования, связанные с переналадками или обслуживанием тоже имею огромный потенциал для воздействия.
Несогласованность взаимодействий приводит к огромным затратам, не ведущим к намеченной цели и часто не окупаемым потребительским спросом. Здесь тоже огромная сфера возможностей влияния.
Нецелесообразность выполнения определенных действия возможна везде, но более всего характеризует бюрократию, производящую работу с показателями. То есть очень большое количество людей реально ежедневно честно выполняет свои работу. Но их работа или вообще не влияет на производимые компаний/проектом товары и услуги или влияет незначительно. Здесь тоже огромная сфера для изменений.
Когда я привожу примеры как действовали военные, Форд, Тойота, Джек Уэлч и т.д. - то объединяет их то, что все они по разному воздействовали на эти три параметра. Применение этих живых примеров в качестве метафоры может позволить проводить аналогичные изменения в компаниях или проектах. Хоть в производственной сфере, хоть в развитии телекома, банкинга или правительственных учреждений. Форд например даже свои благотворительные учреждения сделал самоокупаемыми, потому что использовал эти три показателя.
Борис, зачем здесь стоит слово бережного? - Это относится к теме Бережливое производство?
О чём статья? Японские методы, философия или их западная интерпретация - Lean Manufacturing имеет слабое отношение к тому, о чём говорят авторы Scrum, который продвигается под заимствованным названием Agile. Заимствованными являются и японские термины, в которые они вкладывают другое содержание.
Авторы Scrum - это глубоко погружённые в программирование специалисты, которые "вынырнули" на поверхность делового управления и пытаются сказать, что узкоспециализированные методы годятся для управления, трансформации большой компании. Для стартапа, небольшой команды это где-то работает, а для большой компании нужны другие методы, в том числе Lean Manufacturing. Но это совершенно другой подход )))
Борис, Кайздзен у японцев - это одна сторона медали, но он следует вслед за Кайрё (Kairyo) и они сменяют друг друга. Кайрё в нашем понимании - это Реинжиниринг компании. Вся японская тематика в данной теме "трансформации" компаний ))) - это законспированный восточный антураж, для продвижения, придания теме смысла, которого в ней на самом деле нет. Где-то, что-то задевает краем.
Давайте представим человека, который всю жизнь занимался программированием. Что он знает о японских методах или их западной интерпретации? Можно представить, что просто что-то где-то слышал ))) - это видно по топорному заимствованию части терминологии.
И не надо делать из программиста Гуру в деловом управлении, способным трансформировать большую компанию ))) - авторы Scrum и большинство новоиспечённых специалистов по "трансформации компаний" пришли именно из области программирования и связанных с этим областей деятельности - тестирование, внедрение программных продуктов, постановщики задач программистам и т.п ))) И как уже выше цитировалось от одного из первых авторов по этой теме "трансформаций" на этом ресурсе:
https://www.e-xecutive.ru/management/practices/198...
Андрей, я ввел термин бережное вместо бережливое потому что он проще отражает смысл отношений, на которых основывается бережливое производство(БП).
Я понимаю, что авторы статьи могут подразумевать что то свое. Примерно об этом же писал Деминг, что компании вывешивают лозунги о том, что занимаются БП, но наполняют его совсем другим содержанием и следуют совсем другим курсом. Вероятно это же самое может происходить с Agile. Но именно в манифесте Agile описаны ценности, которые просты в понимании и следуя которым компании могут развиваться. Если руководители компаний будут придерживаться этих ценностей, то они с большей вероятностью смогут фокусировать и направлять сотрудников на решение общих задач.
Я не знаю, смогут ли авторы статьи трансформировать деятельность большой компании? В моем понимании БП надо начинать со стартапа. А в деятельности больших компаний можно делать методами и подходами непрерывные изменения. Сразу станет видно способны ли специалисты производить изменения. Способны ли руководители и специалисты больших компаний следовать изменениям. Ситуации бывают разные и нельзя заранее предсказать исход ситуации, в которой каждый влияет на каждого, как явно, так и скрытно.
Андрей, каждый из нас имеет свое понимание как терминологии, так и ситуации. Если мы займемся изучением того, что мы понимаем и как понимаем, то на это может уйти много времени. Это концептуальное понимание может послужить лишь основой для взаимопонимания. И я даже не понимая Вас в отдельных деталях/терминах, на каком то уровне знаю и чувствую о чем Вы говорите. Конструктивный разговор возможен только в контексте реальной текущей ситуации. Именно в реальной ситуации лучше всего могут проявиться наши разные взгляды и пройденный опыт на неё. Обсуждая это в уважительном русле можно найти такие решения, на которые не способен ни один из нас по отдельности. Можете называть этот менеджмент/взаимодействие как хотите. Я его для себя определил, как "управление знаниями".
Отрывок из книги издательства "Миф" одной очень симпатичной девушки:
Не кормите зверя
В сфере IT работают по Agile. Слово переводится как «проворный», «шустрый». Суть в том, чтобы делить путь к большой цели — на короткие отрезки. В жизни можно и нужно делать так же. Экспериментировать и прислушиваться к себе. Нравится? Продолжайте. Нет? Меняйте вектор.
Так вы минимизируете искушения и экономите силу воли — еще пригодится.
Простой пример. Хочется приготовить полезный завтрак, но раковина забита грязной посудой. Не воодушевляет. И вот вы уже жуете хот-дог. Упс. Поступайте умнее — готовьтесь с вечера: помойте посуду, разложите продукты, поставьте на стол любимую тарелку. И так действуйте во всем.
Грефу такое написать простительно, умной девушке вряд ли.
Профанация - дочь невежества.
Борис, поправьте, если не так, но по этапам:
- Есть утвержденная инструкция, по которой все работают (утвержденное правило).
- Инициируется изменение/дополнение - проводится оценка/расчеты, локальная апробация, тестирование...
- Согласование и утверждение изменений
- Внедрение
- Обучение
ИТОГ:
- Есть НОВАЯ утвержденная инструкция, по которой все работают (утвержденное правило).
Таким образом, каждый сотрудник жестко контролируется, согласно сегодняшней инструкции и до утверждения/обучения по НОВОЙ, все отклонения считаются браком.
Лично для меня, есть следующее понимание:
"Гибкая система снаружи, очень жесткая изнутри" - без утвержденной изменении системы, любое творчество - ПРЕСТУПЛЕНИЕ.
Борис, я написал именно ВОСПИТАНИЕ, как способы и методы применения "мягкой" неформализуемой силы, для достижения поставленных задач. К технологиям и бизнес-процессам это не имеет никакого отношения. Мне приходилось руководить большими командам разработчиков, в том числе и комплексными (от разных компаний и вендоров).
Если Вы можете переложить в технологию и бизнес-процессы форматы общения разработчиков, неформальную поддержку соседа по команде, готовность отступить от своего "Я знаю лучше и ничего у себя менять не буду!" - это заявка на Нобелевскую премию. Даже Дмитрий Новиков в своих трудах по алгоритмизации трудовых отношений не смог этого сделать.
Борису удалось перевести обсуждение статьи на совершенно другую тему и даже расщепить её ... )))
Всё что происходит в Scrum относится к небольшим командам, и даже уже создание такой команды - это Реинжиниринг. Небольшие и непрерывные изменения - это тоже натяжка - не та песня в случае с использованием Scrum - в такой команде каждый день, каждый спринт может поставить всё с ног на голову, и даже привести к смене целей проекта, изменению состава команды и пр. Это максимальная нестабильность во всём.
Погружать в такое "море ужаса" всю компанию будет безумием для руководителя. А борьба за чистоту методов некоторых апологетов может перекрыть всю пользу от этих методов работы ((( Определённый период в Nokia со своим видением Scrum тому пример.
Начну с конца. Без жесткости невозможно постоянство качества. Поэтому в процессе производства нужны стандарты и инструкции, обеспечивающие постоянство качества "изделия", в том числе новыми улучшенными инструкциями. Здесь можно наблюдать определенную жесткость исполнения. Но сами ситуации, связанные с процессом производства непредсказуемы и здесь нужна определенная гибкость. Которой хорошо подходит "канбан бережливого производства".
Есть процессы подготовки производства, включая выбор имеющегося на рынке спроса и ниши, а также НИОКР/проекты. Им хорошо подходит дизайн-менеджмент(дизайн-мышление), Agile(какая точно часть вызывает полемику - поэтому привожу в целом).
В случае, когда требуется развитие компании, проекта можно "погрузившись в ситуацию" определить ограничения. Выбрать из них ключевое или те, на которые можно очень просто и быстро воздействовать. Поставить исполнителю или "кружку качества" задачу на решение. То есть предоставить им возможность проявить инициативу и возможность добиться личных достижений в решение актуальной для компании или проекта задачи.
Специалист по улучшениям стандартов/инструкций опирается на три показателя, которые нужно исследовать, чтобы увеличить скорость, не повлияв на качество или улучшить качество не теряя в производительности. Это потери, несогласованность взаимодействий и нецелесообразность выполнения определенных действий. Эти исследования универсальны для управления. Они могут быть использованы: в производстве, в исследованиях, проектах, военных компаниях и правительственных структурах и т.д.
Например, рассмотрим потери при механической обработке металла. Технолог написал технологию/инструкцию как нужно делать. При этом можно иметь ввиду, что он заложил определенный процент запаса. Также можно иметь ввиду, что появились новые инструменты, способные обрабатывать производительнее и не в ущерб качествам обрабатываемой поверхности. Появились высокоскоростные шпинделя, позволяющие обрабатывать уже закаленные стали, не нанося им температурных воздействий, так как вся температура уходит в стружку, которая при этом сгорает. То есть можно находить возможности для изменения технологий. Даже малые изменения очень сильно влияют на производительность(закон Парето).
Потери при простоях оборудования, связанные с переналадками или обслуживанием тоже имею огромный потенциал для воздействия.
Несогласованность взаимодействий приводит к огромным затратам, не ведущим к намеченной цели и часто не окупаемым потребительским спросом. Здесь тоже огромная сфера возможностей влияния.
Нецелесообразность выполнения определенных действия возможна везде, но более всего характеризует бюрократию, производящую работу с показателями. То есть очень большое количество людей реально ежедневно честно выполняет свои работу. Но их работа или вообще не влияет на производимые компаний/проектом товары и услуги или влияет незначительно. Здесь тоже огромная сфера для изменений.
Когда я привожу примеры как действовали военные, Форд, Тойота, Джек Уэлч и т.д. - то объединяет их то, что все они по разному воздействовали на эти три параметра. Применение этих живых примеров в качестве метафоры может позволить проводить аналогичные изменения в компаниях или проектах. Хоть в производственной сфере, хоть в развитии телекома, банкинга или правительственных учреждений. Форд например даже свои благотворительные учреждения сделал самоокупаемыми, потому что использовал эти три показателя.
Денис!?