Заключение к разделу «Главная сущность менеджмента – «ЗАДАЧА»

Всякий слышит лишь то, что понимает

В начале раздела «Главная сущность менеджмента – «ЗАДАЧА» мы поставили вопрос: что такое «задача» и как её идентифицировать? 

Теперь нужно удостовериться, удалось ли нам ответить на него?

Иначе, стоит ли двигаться дальше, если мы не раскрыли основную суть раздела. Если раздел не даст нам той глубины понимания, которая позволила бы нам однозначно определить и идентифицировать такую сущность, как «задача». 

Как мы без этого понимания, сможем в дальнейшем оперировать «задачей» и строить систему управления потоком ЗАДАЧ, если мы не сможем отделить (отсортировать) её главную сущность от других сущностей.

Итак, удалось или нет? Мне, кажется, удалось.

Учитывая, что в названии раздела я обозначил задачу в качестве сущности, то в самом начале раздела я дал определение понятию «сущность». Указал, что сущность – это не конкретный объект, а ТИП объекта. 

Обозначил, что любая сущность должна обладать предназначением (функциональным назначением) и обязательными атрибутами. Названиями, а не значениями атрибутов. Теперь мы знаем, что такое сущность. И можем определить является ли нечто сущностью или нет.

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

Это позволяет нам относить любую сущность либо к абстрактной, либо к процессной. В УПЗ такое разделение имеет значение. О чём мы поговорим позже.

Далее я описал саму сущность «ЗАДАЧА». Дал ей, на мой взгляд, чёткое определение. Разъяснил каждую фразу, содержащуюся в определении. 

Обозначил, что общее предназначение (функциональное назначение) существования сущности «задача» - обеспечить её выполнением получение целевого результата.  Это означает, что если что-то обладает этим предназначением (функциональным назначением), то, вероятно, это уже задача.

Указал, что «ЗАДАЧА» также является типом, а поэтому сущностью, так как не имеет конкретных значений атрибутов, а обладает только необходимым и достаточным набором их названий. То есть обязательными атрибутами. По их наличию в совокупности с предназначением (функциональным назначением) «задачи» огромное разнообразие всяких конкретных объектов относится или не относится к этому типу – признаётся сущностью «ЗАДАЧА». 

Потом я описал, что не является задачей.  Указал, что задачей не является всё то, что не соответствует определению сущности «ЗАДАЧА». Что не отвечает всей совокупности её ОБЯЗАТЕЛЬНЫХ атрибутов. Одновременно и определению, и всем названиям обязательных атрибутов. 

И заключил, что сущность «ЗАДАЧА» является абстрактной, потому что объединяет две других сущности (подсущности): 

  • абстрактную сущность «процессная задача»[1]
  • абстрактную сущность «целевая задача»[2]

В итоге мы знаем, что «задача» может быть или «процессной задачей», или «целевой задачей». 

Каждая из этих подсущностей имеет свою собственную функциональную специализацию. У каждой есть как общие названия атрибутов, унаследованные от «задачи», так и индивидуальные: у «процессной задачи» - свои, а у «целевой задачи» - свои. Этим я доказал, что «задача» является абстрактной сущностью. 

Забегая вперёд, скажу, что знание о том, что задача является абстрактной сущностью, нам позволит в дальнейшем определить, какая шаблонная дискретная задача (ШДЗ)  должна выполняться в отношении этой сущности: миссия, бизнес-процесс или функция, а, соответственно, какой элемент системы нужно создавать для выполнения этой ШДЗ: систему, субсистему или Реестр процедур

Затем я расписал каждый обязательный атрибут задачи. 

Особо остановился на ЦРЗ. Дал ему определение. 

Написал, что целевой результат задачи (цель) – это качественное и/или количественное описание желаемого конечного состояния и/или положения известного объекта[4], на который или в отношении которого осуществляется воздействие или который получается в результате воздействия на один или несколько других объектов. 

Указал, что это всегда такое состояние и/или положение известного объекта, которое можно почувствовать одним или несколькими органами чувств человека: осязанием, обонянием, слухом, зрением, вкусом и т. д. 

То есть это состояние и/или положение объекта, описываемого в форме существительного, в виде чётко определённого образа того, что мы можем потрогать и/или понюхать, и/или услышать, и/или увидеть, и/или почувствовать на вкус, и/или прочитать.

Благодаря этому сейчас мы ведаем, что такое целевой результат задачи. 

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

Также знаем, что не надо, вообще, ставить задачи, если не можем сформулировать ЦРЗ или требования к нему. 

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

То есть я постулировал, что всё то, результаты чего не измеримы (не оцениваемы) – не есть «ЗАДАЧА». А скорее всего, является чем-то, типа: «МЕЧТА», «ХОТЕЛКА», «ЖЕЛАНИЕ», «ПОТРЕБНОСТЬ», «ЗАДУМКА», «ЗАМЫСЕЛ», «ИДЕЯ» и т. д.

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

Как следствие теперь мы знаем, что от целевого результата зависит суть задачи, её название, содержание и сложность, а также то, почему нельзя считать ЗАДАЧЕЙ всё, что не  имеет целевого результата.

Из этого сделан вывод, что управление появляется только там, где формулируются задачи с целевыми результатами. Что в этом и заключается работа руководителей - в формулировании и делегировании задач с целевыми результатами - в управлении потоком задач. А управление потоком задач - это и есть МЕНЕДЖМЕНТ.

Кроме того, я обозначил, что, если исходить из необходимости выполнения задачи, т. е. из предназначения (функции) существования сущности «задача», то надо чтобы у задачи были также такие обязательные атрибуты, как:

  • Заказчик задачи (ФИО). Тот, кто заказывает и потребляет целевой результат задачи, заинтересован в нём, будет потреблять ЦРЗ, использовать его в своей работе, в выполнении своих задач. Кто принимает ЦРЗ и оценивает достигнут он или нет, а, соответственно, выполнена задача или нет. Одно конкретное ФИО, конкретный человек. В УПЗ заказчик обладает правами акцепта изменения задач.
  • Ответственный выполнитель задачи (ФИО). Тот, кто будет отвечать за выполнение задачи?  С кого будет спрос за невыполнение задачи, за не достижение её целевого результата. Кто понесёт за это ответственность. Кто будет передавать ЦРЗ заказчику, отвечать за его полноту и качество. Взаимодействовать с заказчиком. Одно конкретное ФИО, конкретный человек, а не техническая система. В УПЗ ответственный выполнитель задачи обладает правами в рамках выполнения своей задачи делегировать подзадачи и действия другим сотрудникам. В соответствии с принципом всеобщности. 
  • Срок выполнения задачи (дата). Это, когда задача должна быть выполнена. Когда – это значит «дата», то есть к какой дате должен быть получен ЦРЗ. Конкретная календарная дата. По состоянию на которую мы будем производить ОСДЦРЗ.

Атрибуты: «заказчик задачи» и «ответственный выполнитель задачи»  лежат в основе принципа «петли ответственности» и принципа «крайнего в цепи». Чтобы никто не мог закрыть задачу выполнением без приёмки её результата. Или имитированием её выполнения. Чтобы ответственный выполнитель задачи не мог отменить задачу, забыть про неё, просрочить, необоснованно перенести и т. д

В рамках указанных принципов, а также с использованием принципа всеобщности эти атрибуты в совокупности с атрибутом «срок выполнения задачи» нацелены на обеспечение качества ЦРЗ, гарантированности и своевременности выполнения задач. То есть на преодоление проблемы «неисполнительность», о роли которой мы поговорим в дальнейшем.

Также в настоящем разделе я разделил задачи на функциональные и НЕфункциональные. 

Расписал, что НЕфункциональные задачи – это те задачи, которые на текущем отрезке времени никакого вклада в достижение заданных — желаемых целевых результатов не делают. Они в текущем периоде времени никак не связаны с целями организации, не ведут к достижению этих целей или, даже, противоречат им. Их невыполнение никак не повлияет на достижение целей 

Указал, что есть также псевдозадачи и, что они являются НЕфункциональными задачами. Псевдозадача – это, по сути, задача ради задачи – самоцель. «Псевдозадачи», как правило, выполняются «для галочки» - «на отвяжись», лишь бы отчитаться и забыть про них.

Поэтому далее обозначил, что НЕфункциональные задачи – это потери процесса «менеджмент» (брак, спам, «муда»). Их доля приводит к перерасходу ресурсов, росту затрат и снижению ПИТ. Поэтому с ними надо целенаправленно бороться. 

Объяснил, что в рамках борьбы с ними, мы должны стремиться к выявлению НЕфункциональных задач, к сведению их доли к минимуму. Должны так выстраивать процедуры организации, чтобы исключить или минимизировать количество и/или трудоёмкость НЕфункциональных задач. 

Для этого надо изменять систему управления потоком задач.  И править её надо так, чтобы она не позволяла навязывать организации или провоцировать НЕфункциональные задачи. Надо так структурировать систему управления, чтобы она не давала генерировать и выполнять НЕфункциональные задачи, тратить на них много времени, не создавала благодатную почву для этого, не стимулировала персонал на занятость НЕфункциональными задачами, фильтровала их.

Подвёл, что внедрение системы УПЗ, описанной в настоящем блоге, как раз и есть такая правка системы управления.

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

Кстати, в рамках создания УПЗ введение в задачу в качестве обязательных таких её атрибутов, как ЦРЗ и заказчик задачи, в том числе направлено на борьбу с НЕфункциональными задачами.

Ведь борьба с НЕфункциональными задачами — это в том числе и есть постоянное совершенствование процесса «МЕНЕДЖМЕНТ», то есть — УПРАВЛЕНИЯ ПОТОКОМ ЗАДАЧ. Аналогично борьбе с потерями и браком в физическом производстве. 

Я аргументировал это тем, что когда мы чётко понимаем и принимаем, что управление потоком задач — это процесс «МЕНЕДЖМЕНТ», а НЕфункциональные задачи — потери этого процесса, то мы понимаем, как построить непрерывное совершенствование процесса «МЕНЕДЖМЕНТ», выполняя цикл Деминга (PDCA) и измеряя показатели  процесса — статистику по задачам, в том числе по доле и динамике НЕфункциональных задач.

Статистика по НЕфункциональным задачам позволит достаточно однозначно и конкретно оценивать потери процесса «МЕНЕДЖМЕНТ» и обеспечит постоянство цели совершенствования оного процесса.

Также я описал отличия задачи от цели. Сконцентрировался на том, что для управления сложной организацией надо смещать акцент с целей на задачи. И управлять не по целям, а управлять задачами – точнее потоком задач.

Далее отделил задачу от действия. Описал их различия. Обозначил что задачу надо декомпозировать до уровня действий. Сказал, что действие – это предел декомпозиции задачи. Далее её декомпозировать объективно нет смысла. Объяснил почему. Обозначил что действие – это элементарная частичка задачи. И, что задачу надо выполнять путём исполнения действий, действие за действием. Дал определение действию. 

В результате сказанного теперь мы знаем, что такое задача. Что - это мысленный образ выбранного для достижения целевого результата, НЕ атомарного варианта воздействия человека (или нескольких людей) и/или какой-либо технической системы (или нескольких систем) на известный объект; имеющего характер стимулирующий «активность», а не «пассивность», т.е. отражающего амбицию - инициативное притязание на что-либо; требующего выполнения путём расхода энергии, усилий и ресурсов; обладающего следующими обязательными атрибутами (1) наименование задачи (амбиция) в форме глагола; (2) заказчик задачи (ФИО); (3) ответственный выполнитель (ФИО); (4) срок выполнения (дата); (5) целевой результат задачи (цель).

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

Резюмируем.

Сейчас вы можете идентифицировать задачу, сличая любую сущность с определением, требованиями к обязательным атрибутам и наличием предназначения (функционального назначения) задачи. Способны привести её формулировку в соответствие с заданным в определении стандартом. Можете проверить, не является ли задача НЕфункциональной, псевдозадачей или действием. Не перепутана ли она с целью. Понимаете, что если мы имеем нечто и, если это нечто надо выполнить, чтобы получить целевой результат. Если это нечто является не атомарным воздействием на какой-то известный объект. И это воздействие имеет характер, стимулирующий «активность», а не «пассивность». То есть отражает амбицию - инициативное притязание на что-либо. Если для выполнения требует расхода энергии, усилий и ресурсов. Если это нечто располагает наименованием, в форме  глагола неопределённой формы, совершенного вида (ответ на вопрос: что сделать?), а также обладает ЦРЗ, соответствующим требованиям, имеет заказчика, ответственного выполнителя и срок выполнения. То это задача. И наоборот, если какое-то из перечисленных условий не выполняется, то это не задача. Либо не до конца сформулированная задача, либо вообще другая сущность, например действие.

Таким образом, ответ получен. И вы знаете теперь, что такое задача и как её идентифицировать. Какими атрибутами и отличиями обладает задача, являясь главной сущностью управления. Как её отделить от других сущностей.

В завершении раздела я обозначил, чем порождается задача. Сказал – что проблемами. Дал определение такой сущности как «проблема». Рассказал, почему проблема – это сущность, процессная сущность. Что проблема – это одна из основных сущностей в УПЗ особенно в бизнес-процессах генерирования задач. 

Тем самым я проложил мостик к дальнейшему развитию темы по УПЗ.

Ведь далее мы будем говорить о «проблемах» управления организацией, создавших предпосылки для появления потребности в повышении ПИТ, создании системы УПЗ и разработки ТУЗ. 

Итак, переходим к изучению раздела «Предпосылки появления потребности в повышении производительности интеллектуального труда». В ней мы ответим на вопрос: почему потребность в повышении производительности интеллектуального труда является сверх актуальной на сегодняшний день?

 

Полная версия статьи доступна в моей книге «ЗАДАЧИ ЧУДЕСНЫЕ, ИЛИ КОЗЫРНАЯ «ТУЗ» МОТАЕВА!»

С уважением к Вам и Вашему делу, Мотаев Александр

Обсудить эту и другие статьи блога вы можете в нашем Telegram-канале "Управление потоком задач".


[1] - Подробнее об этой сущности рассказывается в статье «Процессная задача (ПЗ)» в разделе «Система управления потоком задач (Система УПЗ)»

[2] - Подробнее эта сущность описывается далее в статье «Целевая задача (ЦЗ)» в разделе «Система управления потоком задач (Система УПЗ)»

[3] - Читай статью «Понятие «шаблонная дискретная задача (ШДЗ)» в разделе «Задача повышения производительности интеллектуального труда (Задача ППИТ)»

[4] - В том числе нематериального (нефизического) объекта

О блоге

Блог «УПРАВЛЕНИЕ ПОТОКОМ ЗАДАЧ» — это центральное место в Интернет, где описывается и обсуждается:

- архитектура системы Управления Потоком Задач (Система УПЗ);

- облик Технологии Управления Задачами (ТУЗ, Tasks Management Technology, TMT, Total Tasks Management, TTM), по которой работает Система УПЗ;

- семантическое ядро (единый язык) управления потоком задач.

Здесь объясняется, что только с их применением можно значительно увеличить Производительность Интеллектуального Труда (ПИТ) и обеспечить «управление сложностью (разнообразием) организации».

Говорится о том, что управление потоком задач – это и есть процесс «МЕНЕДЖМЕНТ».

Поиск по тегам

 Производительность интеллектуального труда \Система управления потоком задач \Управление потоком задач \Технология Управления Задачами \Задача \ПИТ \ТУЗ \УПЗ \АСУЗ \Интеллектуальный труд \Умственный труд \Total Tasks Management \Tasks Management Technology \постановка задачи \управление задачами \поток задач \Технология всеобщего Управления Задачами \задача (задачи) /цель \Процесс \Процессная задача \Smart \Менеджмент \Организация \Управление по целям \АСУЗ Мириада \Делегирование \Management by objectives \Декомпозиция \Действие \Целевая задача \Управление сложностью \Теория ограничения систем Голдратта \Управление качеством \
©2024 Управление потоком задач. Все права защищены

Поиск