Сергей пишет: Думаю что тема не актуальна.Прописать подробно в инструкции чем надо заниматься,не получиться.

Спасибо за Ваше мнение, Сергей.

Не уверен, что все с ним согласятся на 100%, но все же - это Мнение...

Хорошо. Давайте, чтобы обнажить вопрос об актуальности ДИ, представим себе виртуальную ситуацию, которая, впрочем, вполне может случиться в жизни.

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

Как поступить руководителю этой самой Службы ПС?

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

-Сказать, что ДИ нужны, но их невозможно разработать именно для Службы ПС? Означает поднять шквал недовольства со стороны других руководителей и получить-таки остренькие вопросы в печень: "Это чем же таким секретным занимается служба ПС, что ее деятельность нельзя описать человеческим языком?"

-Третий вариант, который приходит на ум: ничего никому не говорить, а тихонечко написать какую-нибудь муру, утвердить у ГД и надеяться, что про эту муру все быстренько забудут? Очень достойный поступок для Лидера Перемен, не так ли?

Еще варианты поведения предложит кто-нибудь?

В чем прелесть производственной системы,это кажущаяся простота.

Вот именно. Кажущаяся!

Юрий Рыбалка пишет: -Третий вариант, который приходит на ум: ничего никому не говорить, а тихонечко написать какую-нибудь муру, утвердить у ГД и надеяться, что про эту муру все быстренько забудут? Очень достойный поступок для Лидера Перемен, не так ли?

Еще варианты поведения предложит кто-нибудь?

Ну почему ж муру?
Если такая служба уже существует на предприятии, то чем она занимается легко выяснить.
Достаточно виртуально представить, что произойдет в процессах, еслие ее изъять из существующей системы, скажем, на отрезке времени в 1 - 3 года?
Если есть служба, то есть и Потребители этой службы (Выходы процесса), также как и Входы из других Процессов в эту службу.

Как писать должностную инструкцию - я обычно перебираю десятка два-три подходящих вариантов (близких к указанной должности, подразделению...) в интернете + тоже самое из иностранных источников. Складывается некоторая картина, модель, которую можно применить к конкретной задаче (предприятию, системе и пр).

В данном случае - название ПС еще ни о чем не говорит. Что за ПС? Какое ее отличие от других ПС? Слишком широкое понятие...

Как писать инструкции - вот к примеру 12 правил .

Требования к квалификации Lean менеджеров можно посмотреть в форуме lean.org. Построить на этой базе что-то свое.

Можно взять за основу стандарт 9001. Чем плох?

PS Тема полезна. Как и любая другая.

Спасибо, Александр. Блестящие рекомендации!

Теперь хотелось бы определиться еще с одним узловым моментом. Я считаю, что разрабатывать ДИ необходимо ПОСЛЕ того, как разработано Положение о Службе ПС, с целями и задачами. Иная последовательность действий приведет к заведомо ложному результату. При необходимости могу обосновать подробно.

Кто с этим утверждением согласен или не согласен?

Юрий Рыбалка пишет: Теперь хотелось бы определиться еще с одним узловым моментом. Я считаю, что разрабатывать ДИ необходимо ПОСЛЕ того, как разработано Положение о Службе ПС, с целями и задачами. Иная последовательность действий приведет к заведомо ложному результату. При необходимости могу обосновать подробно.

Кто с этим утверждением согласен или не согласен?

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

Александр Филонов пишет: ... но худо-бедно, со скрипом, телега едет? И не обязательно к ложной цели

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

Если телега ТАК едет, то разве не к ложной цели?

Возвращаясь к моему же примеру... Какой смысл писать должностные инструкции сотрудников, если не определены (не сформулированы) цели и задачи подразделения? Из какой логики должны вытечь эти Д.И.? Где гарантия, что без формулировки конечной цели деятельность такого подразделения не является очередным примером локальной оптимизации? (Если не сказать хуже - попросту ИБД ?)

Цель: попытаться понять, а можем ли мы четко и конкретно описать ответственность, задачи и методы Службы ПС? Говоря о методах, не путаем с тем, что мы называем "Инструменты Lean" (да и в общем случае не зацикливаемся только на Lean/TPS), так как внутреннего заказчика вряд ли интересуют сами инструменты,- его интересует конечный эффект от их применения на улучшение текущего состояние актива.

Давайте попробую ответить после долгого молчания. Попробую привести перечень условий, необходимых для функционирования устойчивой системы непрерывного совершенствования.

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

Эта цель декомпозирована по ключевым направлениям, например: коммерсанты отвечают за маржу, оборачиваемость запасов и качество сырья, производство и блок главного инженера - за надежность и экономичность, вспомогательные службы - за качество своего сервиса и эффективность бюджетов по своим направлениям.

Дальше, сформирован некий Устав/Положение о производственной системе, формализующий цели, задачи и ключевые взаимодействия между службами предприятия при реализации программ улучшений. На основании целей и устава сформирован сводный план-график мероприятий со сроками и ответственными. Например, вот такой

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

По сути, то же самое N страницами ранее сказали и В. Худяков:

Здесь я НЕ имею ввиду, что если инструкция гласит, что нибудь вроде: "Выполнение портфеля проектов по совершенствованию, согласно утвержденного плана", то при корректировке этого плана она должна переписываться... Главное грамотно вести сам план...
А вот если мы решили кроме "Внедрения производственной системы" еще и внедрить "систему управления рисками" и поручить этот функционал службе ПС, то вписать это в ДИ стОит. ТАк же со ссылкой на план внедрения СУР.

и Сергей Шурыгин:

Конечно есть.исходя из целей бизнеса.разрабатываем стратегии развития пс, с каскадированием вплоть до бригад.каждый бригадир руководствуется этим документом,снижение нзп внедрять внучку.увеличивая выработку за счет построения потоков и ср,внедрять трм и так далее,очень удобно,каждый бригадир как маленький директор

Спасибо, Александр, за возвращение в ветку, на которую я уж было рукой махнул как на заглохшую. Извините, последние дни был слишком плотно занят.

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

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

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

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

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

Что у нас есть?

1. Цели - на уровне предприятия и ключевых лиц
2. План мероприятий со сроками и ответственными
3. Всякая мелочь вроде операционной деятельности, с которой наши цели и план если не конфликтуют сразу (хотя бы в части ресурсов), то рано или поздно все равно законфликтуют

Так вот - что нужно сделать, чтобы п. 1 был достигнут? Нужно обеспечить выполнение п. 2 (либо, увидев, что он ошибочен - обеспечить оперативную корректировку), максимально "встроив" его в п. 3 (ибо, если перед директором встанет дилемма "сорвать важный заказ или отдать людей на мегаважный проект с отложенным эффектом", 9 из 10 здравомыслящих директоров скажут "Лин лином, а план планом" - и не факт, что будут не правы).

Что нужно для этого сделать?

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

2. Во-вторых, обеспечить всех участников проектных команд необходимыми инструментами для реализации проектов (например, элементарными знаниями в Excel - а то доводилось видеть, как отдельные индивидуумы умудрялись делать таблицы с расчетами в Word. С расчетами сумм и средних на калькуляторе и ручным формированием выборок по цехам, да)

3. В-третьих, обеспечить постоянное увеличение охвата широких масс - хотя бы для более быстрого продвижения по п. 1. Грубо говоря, хотя бы обеспечивать стабильный информационный обмен с персоналом (а это и статьи, и организация встреч, и администрирование баз данных и по обучению, и по рацпредложениям, и куча других обязанностей).

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

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

Нет - сейчас, конечно, придет Андрей Николаевич и скажет (и, возможно, будет даже прав - просто я пока не встречал компаний, где вообще нет проблем с операционкой), что всем этим должен заниматься генеральный директор - и проекты лично контролировать (ежедневно в обейе карандашом отмечать выполнение и изменение ТЭПов, а также писать кучу записок типа "Для выполнения моего поручения от DDMMYYYY прошу выделять главного технолога на целый день для участия в проектах по XX, YY и ZZ каждую среду вплоть до..."), и часть из них вести (и протоколы самому себе писать и согласовывать), и потом еще рабочих обучать экселю (ну или документы на тендер для тренеров готовить), и выступать ("подавая личный пример!") - но, что-то мне кажется, что в компаниях, где у Генерального директора есть столько времени для самостоятельного участия в улучшениях, и службы никакой не нужно

Ну что ж, понемножку логика оформляется... Ваше описание довольно близко, например, к той картине, которую наблюдаю я... Я продолжу в виде вопросов, на которые хотелось бы иметь альтернативную точку зрения, ок?

Иными словами: специалисты ПС - это некий штатный "внутренний консалтинг", так?

Какие мысли, как должно формироваться их вознаграждение? Должны ли они отвечать за достижение каких-то KPI бизнеса, или у них должны быть свои KPI? (лично мне сложновато будет придумать разумные KPI для всех перечисленных видов деятельности).

Не будет ли выглядеть, что эта Служба ПС - некая элитная "священная корова" в коллективе, которая генерирует всеобщую зависть?

Несут ли специалисты ПС ответственность за какие-то бизнес-процессы? Каковы их "рычаги влияния", скажем, на операционных менеджеров, которые не хотят почему-то слышать их рекомендаций по улучшениям?

Юрий Рыбалка пишет: Ну что ж, понемножку логика оформляется... Ваше описание довольно близко, например, к той картине, которую наблюдаю я... Я продолжу в виде вопросов, на которые хотелось бы иметь альтернативную точку зрения, ок?

Иными словами: специалисты ПС - это некий штатный "внутренний консалтинг", так?

Какие мысли, как должно формироваться их вознаграждение? Должны ли они отвечать за достижение каких-то KPI бизнеса, или у них должны быть свои KPI? (лично мне сложновато будет придумать разумные KPI для всех перечисленных видов деятельности).

Не будет ли выглядеть, что эта Служба ПС - некая элитная "священная корова" в коллективе, которая генерирует всеобщую зависть?

Несут ли специалисты ПС ответственность за какие-то бизнес-процессы? Каковы их "рычаги влияния", скажем, на операционных менеджеров, которые не хотят почему-то слышать их рекомендаций по улучшениям?

Я уже писал здесь свои KPI (так же, как и то, что их не выполняю ) - в их числе и выполнение сроков/бюджета проектов, и экономический эффект.

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

Цели по видам деятельности придумать нелегко, но можно - я это (концепт+согласование со всеми+утверждение у ГД) сделал за полгода с помощью двух-трех человек. Ежели помочь нужно - договоримся (я как раз хотел попрактиковаться в оптимизации процессов для строек - у нас очень большая инвестпрограмма )

Я исхожу из какой логики - я здесь, чтобы изменить бизнес - без меня бизнес и так существовал и будет существовать. Соответственно, если результаты бизнеса через некоторое время останутся прежними - то, наверное, будет справедливо, если в разделе Линзоны "Поиск работников, поиск работы" появится новая тема со мною в роли топикстартера

И еще раз насчет ответственности службы на своем примере:

ЗА РЕЗУЛЬТАТ - а) экономический эффект и б) выполнение портфеля проектов

ЗА ПРОЦЕСС - разработка регламентов процессов управления этими проектами и управления системой KPI (в следующем году будет регламенты по рацпредложениям). Замечу, что все создаваемые регламенты, по сути, являются частями более "системных" документов (в частности - Регламента бизнес-планирования).

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