Не уговорившись на берегу, не езди за реку
В предыдущей статье я указал, что частью сути системы УПЗ являются принципы, на которых она строится.
Отсюда возникает вопрос: на каких принципах должна быть построена система УПЗ? Как они должны звучать и что означать?
Отвечаю.
Для повышения ПИТ, необходимо создать систему УПЗ, соблюдающую следующие принципы:
1. принцип главенства задач,
2. принцип всеобщности,
3. принцип «задача порождается проблемой»,
4. принцип единоначалия,
5. принцип измеримости (оцениваемости) задач,
6. принцип «крайнего в цепи»,
7. принцип «петли ответственности».
Принцип главенства задач исходит из признания, что «ЗАДАЧА»[1] является главным объектом управления, то есть ЗАДАЧАМИ надо целенаправленно управлять, для чего необходимо использовать определённые подходы, технологии, методики и инструменты, короче – ТЕХНОЛОГИЮ.
Согласно этому принципу, при управлении организацией всё должно быть подчинено выполнению задач. То есть сначала настраиваем управление задачами, а точнее потоком задач, затем этому подчиняем управление всеми остальными объектами: персоналом, деньгами, информацией, знаниями и т. д.
Под выполнение и для выполнения задач должны:
1. подтягиваться ресурсы: человеческие, материальные, финансовые и др.,
2. настраиваться коммуникации, документооборот и обмен данными, информацией,
3. распределяться полномочия: обязанности, права, компетенции и ответственность,
4. производиться изменения в организации,
5. и т. д.
Принцип всеобщности предполагает:
1. включение (вовлечение) в контур управления потоком задач всех сотрудников интеллектуального труда всех уровней управления, включая первое лицо организации. То есть участвовать в потоке задач и использовать Технологию Управления Задачами (ТУЗ)[2] должны все сотрудники организации, невзирая на ранги. А первое лицо: директор, президент, руководитель госоргана, в первую очередь. Никаких исключений.
2. стирание границ между структурными подразделениями и иерархическими уровнями управления. Это означает, что все сотрудники интеллектуального труда могут ставить задачи друг другу: по горизонтали, по вертикали и по диагонали, независимо от уровня управления и наличия границ между структурными подразделениями. Главное, чтобы задачи ставились по назначению, тем работникам, кто должен и может их выполнить, или может повлиять на их выполнение, исходя из специализации и распределения обязанностей и полномочий внутри организации.
3. охват всех задач всех видов:
3.1. целевые задачи: целевые стратегические задачи (ЦСЗ) и запоточенные целевые задачи (ЗЦЗ)
3.2. процессные задачи: шаблонные дискретные задачи (ШДЗ) и шаблонные эпизодические задачи (ШЭЗ), процедуры, операции, запоточенные дискретные задачи (ЗДЗ), запоточенные эпизодические задачи (ЗЭЗ).
так как необходимо управлять движением ОДНОВРЕМЕННО всех видов задач, составляющих поток задач. В противном случае не создать целостный поток задач, дающий представление о «загрузке» системы УПЗ, о её «узких» местах и потерях в ней.
Благодаря этому принципу ТУЗ можно ещё назвать Технологией всеобщего (тотального) управления задачами (Total Tasks Management, TTM) по аналогии со Всеобщим управлением качеством (Total Quality Management, TQM).
Принцип «задача порождается проблемой» говорит о том, что в управлении потоком задач для определения сути и необходимости выполнения какой-либо задачи, сначала необходимо определить - проблему, которая мешает организации двигаться далее. Ведь задача порождается проблемами[3] (от греч. problema — преграда, трудность), то есть встречей потребности с сопротивлением, препятствием.
Отсюда, проблема – это одна из сущностей управления потоком задач. Она через потребность объясняет, для чего нужна задача по её преодолению, путём удовлетворения потребности. Поэтому надо всегда формировать связку «проблема→задача» посредством формулирования потребности.
Эта логика применяется в ТУЗ при моделировании алгоритмов реализации задач всех видов и позволяет легко генерировать нужные задачи, проверять логические взаимосвязи между ними, выстраивать последовательности, инвентаризировать объём задач и много другое.
Принцип единоначалия. Его ещё никто не смог отменить со времён Моисея. И никогда не отменит, несмотря на новомодные идеи о «плоских» оргструктурах и неформальных командах.
Все организации и органы власти[4] — это иерархические структуры, где принцип единоначалия является и будет являться незыблемым. Он естественен в силу иерархической природы всего сущего.
Иерархия определяет целостность системы. Нарушение единоначалия разрушает иерархию, а, следовательно, целостность системы. Ведёт к энтропии.
Отсюда, мы исходим из того, что принцип единоначалия должен соблюдаться и при управлении потоком задач. Вернее так: управление потоком задач, основывается на признании необходимости соблюдения принципа единоначалия.
Это достигается тем, что при постановке задач, с учётом принципа «всеобщности», непосредственный руководитель мог участвовать в цепочке команд в адрес его подчинённых и мог влиять на процесс «озадачивания» его подчинённых.
Кстати, управление потоком задач с применением ТУЗ, а в её составе – АСУЗ, позволяет не отменять принцип единоначалия, а существенно расширять норму управляемости.
Кроме того, использование наравне других принципов УПЗ, позволяет избегать такой ситуации, когда, жёстко соблюдая принцип «единоначалия», непосредственный руководитель становится «узким горлышком» в распределении задач или превращается в «феодала», правящего своим «удельным княжеством» со своими приоритетами.
Существует лишь то, что можно измерить
Макс Планк[5]
Принцип измеримости (оцениваемости) задач заключается в том, что ставить и выполнять надо только те задачи, результаты выполнения которых можно достаточно легко и достоверно оценить и измерить. Все задачи, результаты выполнения которых нельзя измерить и оценить не должны включаться в поток задач. Это, в моём понимании, и не задачи вовсе. Скорее это «хотелки», намерения, но не задачи.
Поэтому все задачи обязательно должны обладать целевым результатом[6].
Это полностью отвечает требованиям техники SMART-управления[7], обеспечивая наличие такой характеристики как: (М) Measurable/Измеримость.
Целевой результат является тем стандартом, по которому оценивается степень выполнения задачи.
Не надо, вообще, ставить задачи, если:
1. не знаете, как будете оценивать степень достижения целевого результата задачи,
2. не можете сформулировать целевой результат задачи или требования к нему,
3. не способны организовать достоверную оценку целевого результата задачи,
4. не можете создать механизмы, позволяющие произвести оценку степени достижения целевого результата задачи,
5. и тем самым не можете исключить «формализм» в выполнении задач
6. и т. д.
Принцип «крайнего в цепи» состоит в том, что ответственность за невыполнение задачи лежит на том, на ком остановилась (зависла) цепочка задач.
Часто одной из причин невыполнения задачи одним сотрудником является невыполнение предшествующей задачи другим – смежным сотрудником (проблема кросс-функционального НЕвзаимодействия[8]).
Так вот в УПЗ, этот аргумент может приниматься только при условии, что первый сотрудник при выполнении своей задачи, декомпозировал её и, по цепочке поставил предшествующую задачу смежному сотруднику (выступив тем самым заказчиком задачи[9]), а тот принял и не выполнил. Или выполнил, но не качественно и заказчик задачи её не принял.
В результате первый сотрудник не смог выполнить свою задачу. Виновный второй сотрудник, так как на нём остановилась цепочка задач. При этом возможность ставить задачи смежным сотрудникам предоставлена принципом «всеобщности».
Такая модель заставляет создать стимулы для декомпозиции и делегирования задач по цепочке. Что, по сути, «вытягивает» всю цепочку необходимых к выполнению задач и обеспечивает её исполнение целиком от начальной задачи до конечной.
Кроме того, это в совокупности с принципом «петли ответственности» позволяет по-честному определить «крайнего». Что немаловажно и жизненно необходимо для иерархических структур управления. Где всё строится на ответственности сотрудников.
Без ответственности наступает безответственность. В общественных системах, построенных на выполнении задач людьми, это приводит к «протуханию» и последующему разрушению организаций.
Но встаёт вопрос: как найти действительно виновного в невыполнении задачи? Ведь мы не можем не искать его. Иначе наступит упомянутая выше безответственность с вытекающими последствиями.
В этом случае уместно вспомнить ряд афоризмов по теме:
- «есть два способа разложить нацию: наказывать невиновных и не наказывать виновных» (Фридрих Энгельс[10]);
- «жалеть виновного, значит предать невинных» (Айн Рэнд[11]);
- «обвинить можно и не виновного, но обличить – только виновного» (Апулей[12])
С учётом этого можно сказать, что сотрудники должны отвечать за невыполнение задач, но только если в этом виновны.
Отсюда, «виноватых искать» - необходимо, только важно это делать обоснованно и объективно, справедливо. Этому и помогает настоящий принцип.
Без этого принципа будет всё, как на флоте: «любое начинание всегда делится на четыре стадии: первая — запугивание; вторая — запутывание; третья — наказание невиновных; четвертая — награждение непричастных». Или как в анекдоте про стадии проекта: «1 — Шумиха; 2 — Неразбериха; 3 — Поиск виновных; 4 — Наказание невиновных; 5 — Награждение непричастных». 
Избегать сказанного в управлении потоком задач позволяет наличие цепочки задач, и нахождение крайнего в цепи. А также следующий принцип.
Принцип «петли ответственности»[13] предполагает распределение и зацикливание (закольцовывание) ответственности за выполнение цепочки задач таким образом, чтобы созданная петля гарантировала выполнение задач в цепи в заданные сроки и с необходимыми уровнями качества их целевых результатов.
Принцип «петли ответственности» должен соблюдаться при выстраивании любых цепочек задач в управлении потоком задач. Он должен распространяться и на процессные, и на целевые задачи. Без исключения.
Для реализации принципа «петли ответственности» в обязательные атрибуты задачи наравне с «ответственным выполнителем задачи (ФИО)»[14] введён «заказчик задачи (ФИО)»[15].
При этом обязательно необходимо, чтобы заказчик задачи (в лице конкретного человека) не был её же ответственным выполнителем. То есть эти роли должны выполнять физически разные люди.
Нельзя допускать, чтобы ответственный выполнитель сам себе в качестве заказчика формулировал задачи, сам их себе ставил и закрывал выполнением. Принимая сам у себя целевые результаты их выполнения, оценивая их степень достижения. За исключением ситуации, когда организация представляет из себя одно лицо. Например, индивидуального предпринимателя или учредителя, директора и исполнителя в одном лице.
Это главное требование принципа «петли ответственности».
Этот принцип ОСОЗНАННО, путём введения заказчика задачи, закладывает и создаёт условия для возникновения мелких «конструктивных противоречий (конфликтов)» на местах. Между заказчиками и ответственными выполнителями задач. Разрешение которых будет гарантировать качество и сроки выполнения задач. Прояснять требования к ЦРЗ, составу, последовательности, срокам и границам задач в их цепочке. Выявлять недостатки. Как говорится, «на то и кот, чтобы мыши не дремали».
Я считаю, что для развития и совершенствования, а также устойчивости организации лучше регулярно иметь и разрешать тысячи конструктивных противоречий (конфликтов), чем накапливать и разрешать одно огромное ДЕСТРУКТИВНОЕ противоречие (конфликт). Которое может стать болезненным или даже фатальным для организации.
Принцип «петли ответственности» не даёт застояться организации. Он регулярно перетряхивает организацию. Заставляет шевелиться как заказчиков задач, так и ответственных выполнителей. Они друг друга держат в тонусе. Реализуется условие: «если кошка проворна, то и мышь шустра».
Давайте опишем логику работы принципа «петли ответственности» на примере. Для начала нарисуем цепочки задач, для наглядности и описания примера.
Рисунок «Пример цепочек задач для демонстрации принципа «петли ответственности»
На представленном рисунке мы видим две цепочки целевых задач.
Первая - верхняя – это цепь задач, по выполнению такой задачи верхнего уровня, как «Создать систему УПЗ». Обозначим её З1. Её ответственный выполнитель – Мотаев.
Цепь задач по выполнению З1 состоит из трёх последовательно выполняемых задач:
- З1.1 – «Спроектировать систему УПЗ». Ответственный выполнитель – Мотаев.
- З1.2 – «Сконструировать систему УПЗ». Ответственный выполнитель – Петров.
- З1.3 – «Настроить систему УПЗ». Ответственный выполнитель – Иванов.
Вторая – нижняя – это цепь подзадач, по выполнению З1.1 – «Спроектировать систему УПЗ». Эта цепочка получена в процессе декомпозиции З1.1 и состоит также из трёх последовательно выполняемых задач:
- З1.1.1 – «Спроектировать субсистему генерирования процессных задач (ГПЗ)». Ответственный выполнитель – Сидоров.
- З1.1.2 – «Спроектировать субсистему генерирования целевых задач (ГЦЗ)». Ответственный выполнитель – Сидоров.
- З1.1.3 – «Спроектировать субсистему выполнения запоточенных задач (ВЗЗ)». Ответственный выполнитель – Мотаев.
По умолчанию согласно принципа «петля ответственности» заказчиком каждой предыдущей задачи, должен быть ответственный выполнитель следующей за ней задачи. Но при условии – если это разные люди.
Согласно этому правилу, в нашем случае, если выполнитель З1.1 - Мотаев, то заказчиком З1.1 должен быть выполнитель З1.2 – Петров.
Петров должен осуществлять акцепт либо не акцепт выполнения З1.1, а также любых её изменений. Ему выполнять З1.2 и ему отвечать за сроки и качество выполнения З1.2. А так как З1.2 зависит от выполнения З1.1, то он заинтересован в требовании выполнения З1.1 в срок и с необходимым качеством. Иначе, в случае чего, он согласно принципа «крайнего в цепи» окажется виновным. Такая логика заставляет Петрова постоянно требовать выполнения З1.1, контролировать сроки и оценивать качество полученного ЦРЗ.
Аналогичная ситуация в паре «З1.2→З1.3». Иванов должен быть заказчиком З1.2, так как он другой человек и выполнитель З1.3, следующей за З1.2.
Возникает вопрос, а кто должен быть заказчиком З1.3? Ведь у неё нет следующей задачи.
Отвечаю: ответственный выполнитель ВЫШЕСТОЯЩЕЙ задачи - З1. В нашем случае – это Мотаев. Именно он отвечает за выполнение всей вышестоящей задачи, и он заинтересован в сроках и качестве выполнения последней подзадачи в первой цепи задач.
Рассмотрим далее пару «З1.1.1→З1.1.2» во второй – нижней цепочке задач.
В ней за выполнение этих обоих задач отвечает один человек – Сидоров. То есть у предыдущей задачи и следующей за ней задачи один выполнитель. Согласно принципа «петли ответственности» один и тот же человек не должен совмещать в одной задаче роль и заказчика и ответственного выполнителя. Поэтому Сидоров не может быть заказчиком З1.1.1. Несмотря на то, что он выполнитель следущей задачи. Тогда, кто может?
Отвечаю. Выполнитель ВЫШЕСТОЯЩЕЙ задачи - З1.1. То есть Мотаев. Он отвечает за выполнение всей задачи, частью которой является З1.1.1. И он наиболее заинтресован в том, чтобы все подзадачи из цепи задач, относящихся к З1.1, были выполнены в срок и с необходимым качеством. Иначе он просрочит свою З1.1.
У нас есть ещё одна уникальная ситуация во второй – нижней цепочке задач. Это З1.1.3.
Она крайняя во второй цепи задач. То есть не имеет следующей задачи. И её выполнитель Мотаев. Он же является выполнителем вышестоящей задачи. Поэтому он не может быть заказчиком задачи З1.1.3.
Вопрос, а кто тогда? Тогда – Петров. Он является выполнителем З1.2. То есть он заинтересован в итогах выполнения всей З1.1. Он будет потреблять её ЦРЗ при выполнении своей З1.2. А так как З1.1.3 является финишной подзадачей в З1.1, то её результат и будет нужен Петрову для выполнения его З1.2 поэтому он и должен быть заказчиком З1.1.3.
Вот такие петли необходимо закручивать при соблюдении принципа «петли ответственности». Главное его предназначение: задать мотивы и стимулы для вытягивания цепочек задач, гарантированного, своевременного и качественного их выполнения. Он по сути создаёт «круговую поруку» со знаком «+». Где все заинтересованы в выполнении задач.
В управлении потоком задач все описанные выше принципы обязаны соблюдаться полностью и одновременно. Совокупно. Нельзя один принцип соблюдать, а другой нет. В противном случае не будет нужного результата или даже наоборот, будет отрицательный результат. Так как возникнут не нужные диспропорции и перекосы.
Кто осознанно нарушает указанные принципы, тот осознанно разрушает систему УПЗ, дестабилизирует её.
Создавая, совершенствуя, изменяя любую часть системы УПЗ, мы должны соотносить это действие с перечисленными выше принципами. Должны выяснять, не нарушает ли вносимое изменение какой-либо из указанных принципов системы УПЗ.
Если нарушает, то как сделать так, чтобы не было нарушения ни одного из указанных принципов. Если внести изменения в систему УПЗ, не нарушив один или несколько из перечисленных выше принципов невозможно, то необходимо отказываться от его реализации.
Из сказанного выше следует, что система УПЗ соблюдает принцип главенства задач, принцип всеобщности, принцип «задача порождается проблемой», принцип единоначалия, принцип измеримости (оцениваемости) задач, принцип «последнего в цепи», принцип «петли ответственности». В УПЗ все описанные принципы обязаны соблюдаться полностью и одновременно. Совокупно. Нельзя один принцип соблюдать, а другой нет. Эти принципы положены в основу создаваемой системы УПЗ. То есть, в системе УПЗ все её элементы безоговорочно подчиняются этим принципам, следуют им, настраиваются с их учётом и отвечают им.
Итак, договорившись о принципах системы управления потоком задач, давайте перейдём к вопросу, какие системные требования определяют свойства системы УПЗ?
Полная версия статьи доступна в моей книге «ЗАДАЧИ ЧУДЕСНЫЕ, ИЛИ КОЗЫРНАЯ «ТУЗ» МОТАЕВА!»
С уважением к Вам и Вашему делу, Мотаев Александр
Обсудить эту и другие статьи блога вы можете в нашем Telegram-канале "Управление потоком задач".
Ссылки на мои иные комментарии, относящиеся к теме настоящей статьи:
[1] О задаче, как главном объекте управления, я рассказывал выше, в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
[2] О Технологии Управления Задачами я рассказываю дальше, в разделе 7. «Технология Управления Задачами (ТУЗ)».
[3] Об этом я говорил выше, в статье «Чем порождается задача?» в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
[4] Да и не только организации и органы власти, все системы вселенной и сама вселенная – это иерархические структуры.
[5] Макс Карл Эрнст Людвиг Планк (23.04.1858 — 4.10.1947) — немецкий физик-теоретик, основоположник квантовой физики. Лауреат Нобелевской премии по физике (1918) и других наград, член Прусской академии наук (1894), ряда иностранных научных обществ и академий наук. На протяжении многих лет один из руководителей немецкой науки
[6] Смотри статью «Что такое целевой результат задачи?» выше в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
[7] Читай статью «Техника SMART» в разделе 8. «Применяемые в ТУЗ известные методики, методологии и теории».
[8] Читай выше статью «Кросс-функциональное НЕвзаимодействие» в разделе 4. «Ключевая разовая проблема, мешающая повышению ПИТ».
[9] Читай статью «Заказчик задачи (ФИО)» выше в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
[10] Фридрих Энгельс (28.11.1820 — 5.08.1895) — немецкий политический деятель, философ, историк и предприниматель. Один из основоположников марксизма. Друг и единомышленник Карла Маркса, и соавтор его трудов.
[11] Айн Рэнд (20.01.(2.02) 1905 — 6.03.1982) — американская писательница и философ, родившаяся в Российской империи. Она известна своими двумя романами-бестселлерами — «Источник» и «Атлант расправил плечи»; работала также как драматург и сценарист. Айн — создательница философской системы, названной ею объективизмом.
[12] Апулей (лат. Apuleius, родился в 124/125 н. э. в Мадавре, римская провинция Африка) — древнеримский писатель и поэт, философ-платоник, ритор, автор знаменитого романа «Метаморфозы» («Золотой осёл»).
[13] По аналогии с «петлёй времени» (временной петлёй, кольцом времени)
[14] Читай статью «Ответственный выполнитель задачи (ФИО)» в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА»
[15] Читай статью «Заказчик задачи (ФИО)» в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
