Как доложить руководителю о проблеме?


13 года 6 мес. назад #4536 от Вячеслав Марков
Александр Карбаинов писал(а):

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

Меня попросили разработать порядок доклада о проблеме (или где-нибудь найти).

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

А регламент, какой бы он замечательный не был, кол-во проблем не уменьшит, а уменьшит кол-во обращений к руководству, чтобы голова не болела... Проблемы-то останутся. :)

Лично я поддерживаю метод флипчартов в качестве проблемных досок, о которых писал Игорь. Чтобы все видели, что за проблема, как решать, когда и кому. Как на Микроне.

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


13 года 6 мес. назад #4542 от Александр Карбаинов
Александр Филонов писал(а):

У Карнеги методика свелась к четырем пунктам.

Cотрудник обязан подготовить записку с ответами на четыре вопроса:

1. В чем суть проблемы (ясно сформулировать, что волнует)
2. В чем ее причина (ясно изложить факторы, которые обусловили проблему)
3. Каковы возможные решения (варианты)
4. Что конкретно вы предлагаете (для исключения любителей ходить "вокруг да около") :)

"Что конкретно вы предлагаете" можно расценивать двояко: "Как потушить пожар?" и "Как сделать, чтобы он более никогда не возник?"
Хотелось бы иметь ответ на оба вопроса.
Кроме того, начальники бывают разные. Именно поэтому я предложил задать стандрат работы и для них.

Keep it simple, stupid!

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


13 года 6 мес. назад - 13 года 6 мес. назад #4543 от Александр Карбаинов
Вячеслав Марков писал(а):

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

На гембу, если она физически существует. А если нет? На какую гембу пойдёт, например, руководитель подразделения программистов?

А регламент, какой бы он замечательный не был, кол-во проблем не уменьшит, а уменьшит кол-во обращений к руководству, чтобы голова не болела... Проблемы-то останутся. :)

Лично я поддерживаю метод флипчартов в качестве проблемных досок, о которых писал Игорь. Чтобы все видели, что за проблема, как решать, когда и кому. Как на Микроне.

Флипчарты это уже регламент.

ПС. Результат выложу к среде.

Keep it simple, stupid!

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


13 года 6 мес. назад - 13 года 6 мес. назад #4544 от Александр Карбаинов
Юрий Рыбалка писал(а):

Я имею ввиду, что право немедленно остановить конвейер при обнаружении проблем принадлежит любому рабочему, обслуживающему этот конвейер.

Но будет ли это эффективно, если речь идёт о службе техподдержки или об отделе продаж?

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

Keep it simple, stupid!

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


13 года 6 мес. назад #4545 от Наталья А
Александр. Ваша схема понятна и полезна.
я с удовольствием воспользовалась бы ей в собственной деятельности.
Однако, по моему опыту, главным препятствием станут
1)сложность формулировки проблемы.
2) выявление причины ее возникновения.
К сожалению, именно неумение формулировать и диагностировать проблему и является основным препятствием в решении.
если бы подчиненные умели это делать самостоятельно - они бы не были подчиненными.
у меня в подчинении ВСЕ специалисты с В/О, однако, и у них возникают проблемы с "формулировкой проблемы" (простите за каламбур!)
Флипчарт с сигнальной карточкой мне кажется подходящим вариантом. тогда, появится возможность группировать задачи по функциям и причинам возникновения.

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


13 года 6 мес. назад #4546 от Александр Карбаинов
Наталья А писал(а):

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

Проблемы подчинённых в этом общие :) Вот пускай начальники их и учат. И заодно, сами.

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

Keep it simple, stupid!

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


13 года 6 мес. назад - 13 года 6 мес. назад #4547 от Наталья А
именно в качестве протокола я ваше предложение сочла для себя полезным.
Спасибо,еще раз :)
однако, оно же не исключает возможность применения сигнальных карточек.

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


13 года 6 мес. назад - 13 года 6 мес. назад #4548 от Юрий Рыбалка
Юрий Рыбалка писал(а):

Я имею ввиду, что право немедленно остановить конвейер при обнаружении проблем принадлежит любому рабочему, обслуживающему этот конвейер.


Александр Карбаинов писал(а):

...в оригинале конвейер останавливается при наличии брака, а не проблем. А здесь есть разница.


Насколько я понимаю, в оригинале проблемой считается любое отклонение от стандарта. В т.ч. и брак.

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

Но будет ли это эффективно, если речь идёт о службе техподдержки или об отделе продаж?


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

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

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

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

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

Все же, о классификации проблем для доклада:

Когда мы внедряли производственный анализ на стройке, бланк отчета о причинах невыполнения плана делился на 3 категории: Люди, Материалы, Механизмы. В графе "причина" уже указывался не любой пришедший в голову бред, а указание на происшествие в одной из данных категорий обеспечения производственного процесса. Соответственно, обязанность реакции на проблему распределялась по линии Отдела персонала, ОМТС или Службы механика.

А с какой проблемой (производственной) может придти программист к генеральному директору, например, я ума не приложу...

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


13 года 6 мес. назад #4549 от Андрей Николаевич
Александр Карбаинов писал(а):

...На какую гембу пойдёт, например, руководитель подразделения программистов?

Александр,
гемба это место возникновения проблем! Если проблема возникла у программиста, то начальник едёт к программисту и решает его проблему.
Юрий,
примеры проблем программиста, решение которых зависит от ген.директора: "Монитор низкого разрешения, устают глаза", "Лимит на бумагу крайне низок, и её качество оставляет желать лучшего. Зато дешёвая. Комерсы отказываются покупать другую.", "Устаревшее программное обеспечение" и т.д.

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


13 года 6 мес. назад #4550 от Игорь Рыжкин
Андрей Николаевич писал(а):

Юрий,
примеры проблем программиста, решение которых зависит от ген.директора: "Монитор низкого разрешения, устают глаза", "Лимит на бумагу крайне низок, и её качество оставляет желать лучшего. Зато дешёвая. Комерсы отказываются покупать другую.", "Устаревшее программное обеспечение" и т.д.


К Гене вообще нечего ходить с проблемами. Он только должен ставить подпись под приказом с готовым решением. Иначе на кой ему функциональные директора и замы?

Боишься - не делай, делаешь - не бойся!

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

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