Comments 11
Хочу попросить разобрать на примере. Например, руководитель службы поддержки. Задачи его сотрудников не связаны с его задачами. Сотрудники решают инциденты. Менеджер отвечает за непрерывность процесса: сотрудник заболел, нужна замена. Таким образом есть
задачи только его, как менеджера, а не его сотрудников
задачи ситуативные
если задач 0, то это не говорит о его неэффективности как менеджера.
непонятно, как утверждение менеджмент = управление задачами использовать для эффективности данного примера
Михаил, добрый вечер. Когда я говорю, что Управление потоком задач (УПЗ) - это менеджмент, я имею ввиду менеджмент ОРГАНИЗАЦИИ, а не отдельного подразделения. Поток должен быть сквозным. Всеобщим. Это принцип "всеобщности". Он описан здесь: http://potokzadach.ru/index.php/all-blog/115-sistema-upz/257-principy-sistemy-upz
Исходя из этого принципа, под сотрудниками я понимаю всех сотрудников организации, включая руководителей всех уровней. Они ведь тоже сотрудники. В том числе первое лицо. Ведь у всех есть задачи. Если нет задач, то и делать то нечего. Тогда вообще зачем сотрудники или руководитель?
Все задачи я делю на два вида: процессные и целевые.
В свою очередь процессные задачи подразделяются на: дискретные и эпизодические. Эпизодические - это такие задачи, которые стартуются при наступлении "запускающего события (ЗС)". Подробнее здесь: http://potokzadach.ru/index.php/all-blog/116-tuz/292-ponyatie-shez. Различия между дискретными и эпизодическими задачами я описываю здесь: http://potokzadach.ru/index.php/all-blog/116-tuz/454-razlichiya-mezhdu-dz-i-ez
Эпизодических задач в общем потоке задач при хорошо отлаженных процессах и процедурах 90%
В вашем случае эпизодические - это видимо "ситуативные". По идее при наступлении ЗС "нужна замена", должна выполняться стандартная эпизодическая задача, что типа "Найти (или подобрать) замену выбывшему сотруднику". Событие стандартное и задача должна быть стандартная (я называю её шаблонной). То же самое и с инцидентами. Наступило ЗС "произошёл инцидент" опять же должна запускаться и выполняться стандартная эпизодическая (в вашей терминологии - ситуативная) задача типа "Устранить инцидент и его последствия".
Спасибо за ответ. Я еще подумал, что задача - это квант процесса.
В статьях основной целью является увеличение производительности интеллектуального труда. Если разбивать на задачи, то все упирается в понятие сложности задачи.
В случае с руководителем, если у него не возникла задача "найти замену", то он работает неэффективно, так как количество задач = 0?
В случае с сотрудником поддержки. Один сотрудник закрыл 1 задачу в неделю, а второй 4. Но у первого задача могла быть сложнее во много раз. Или наоборот она для него сложная, так как он имеет небольшой опыт.
Как решается в данной теории проблема сложности задач, или отсутствия задач?
Сложность решается декомпозицией задач. И их стандартизацией. А отсутствие задач - это на мой взгляд нонсенс. Что значит нет задач? Задачи должны быть всегда. Иначе, для чего нужен человек? Что он делает в это время? Спит? Думаю надо более подробно вникать в суть вашей деятельности.
Есть два примера.
Первый - упрощенный. Охранник, который открывает шлагбаум только разрешенным автомобилям. В один день он открыл его 5 раз, а в другой день 10, а в третий 1. По характеру его работы нельзя понять какая у него производительность.
Второй - усложненный. Техподдержка решает инциденты. Все инциденты разные. Скорость их решения зависит от десятка параметров: известности проблемы, наличия решения в базе знаний, возможности исправить проблему удаленно и т.п.
Например у двух заказчиков одинаково повредилась база данных. Первый инженер исправил проблему удаленно за 4 часа. Второму пришлось ехать на место, и он исправил ее за 2 дня. Оба решили одну задачу, но с разной производительностью. И сложно понять как это использовать в процессах.
По охраннику - вы можете отнести его к работникам интеллектуального труда? Лично я нет.
По техподдержке и инцидентам. Количество задач определяется количеством сущностей, которыми вы оперируете. Почитайте здесь: http://potokzadach.ru/index.php/all-blog/121-disput-po-menedzhmentu/192-tuz-eto-upravlenie-vozrastayushchej-slozhnostyu.
С в случае с выездом у вас две сущности: инцидент и адресат. То есть задачи как минимум три: съездить на адресат, устранить инцидент и его последствия и вернуться с адресата. У вас должно быть два реестра процедур (РП). РП по ИНЦИДЕНТАМ И РП по АДРЕСАТАМ. Если у вас инциденты делятся на разновидности, то у вас может быть под каждый вид свой Реестр процедур. Как то так. А более подробно, надо глубже вникать
Не могу согласиться с таким подходом. Это будет бесконечное разбиение на более мелкие задачи и соответствующие реестры: оформление командировки, проведение по бухгалтерии, покупка билетов и бронь гостиницы, отчет по командировке, согласование доступа на объект.
Теория в любом случае интересна. Мне кажется, что подход задача - квант процесса реален. Возможно имеет смысл сфокусироваться на KPI процесса, а не отдельного кванта.
Ваше право не соглашаться. Бесконечного разбиения не будет. Я давно живу. И много чего на практике пробовал. KPI - это бред. Не надо меня учить тому, что я десяток лет назад проходил. В теории менеджмента вы меня ничем не удивите. Я ведь не экспериментирую, не ищу решения. Я описываю то, что уже осмыслено и реализовано. Я ведь никого не учу, никому ничего не доказываю. Просто описываю решение. Делюсь опытом и наработками. И если вы не восприняли, то это хуже не для меня, а для вас. У меня то всё работает. У меня целостная система УПЗ. И это не теория, не концепция, не фантазия, а полностью спроектированная и опробованная на практике технология. Она полностью разработана. Я сейчас под неё разрабатываю программу. В 2005-м уже была пробная версия. Она работает. Сейчас будет полностью переработана. Так как и морально и физически устарела. Я ведь не кабинетный теоретик, и НЕ консультант, а действующий предприниматель и бизнесмен: http://potokzadach.ru/index.php/home/ob-avtore. Всё через практику выстрадано. 18 лет этому посвящено. С 25 лет на руководящих постах как никак, на первых ролях. Так что знаю, что делаю. И что говорю. И речь идёт не о квантах. Вы просто не поняли логику. Если взять за основу что-то другое, тогда целостность системы разрушится. А KPI - это детская болезнь Все ей болеют в "детском" руководящем опыте Удачи вам.
Я совершенно не пытаюсь опровергнуть этот подход. Мне интересно посмотреть на решение практической задачи. Как будет построена оценка эффективности отдела технической поддержки. Кроме как использовать kpi точек процесса другого подхода у меня не было.
Не обязательно здесь и сейчас. Можно в виде отдельной статьи потом.
УПЗ – это «МЕНЕДЖМЕНТ»