Наша дуда - туда и сюда
Ранее в статье «Понятие «шаблонная дискретная задача (ШДЗ)» в разделе 5. «Задача повышения производительности интеллектуального труда (Задача ППИТ)» я обозначил, что функция – это дискретная задача, выполняемая путём воспроизводимого выполнения одной и той же процедуры[1], запускаемой многократно, регулярно, раз от раза, эпизодически, и выполняемой итерационно в отношении каждого вновь появившегося конкретного процессного объекта (КПО) контекстной процессной сущности (ПС).
Затем в статье «Реестр процедур – это узел системы – процессная сущность» выше в разделе 6. «Система управления потоком задач (Система УПЗ)» я написал, что Реестр процедур, как элементарная частица системы, как узел системы, обеспечивает воспроизводимое выполнение определённой дискретной задачи – функции.
Далее, уже в настоящем разделе, я показал взаимосвязь функции с процедурой. То есть связь «ДЗ→ЭЗ». Обрисовал и процедуру, и её типовое строение. Представил процедуру визуально. Описал сам Реестр процедур, через который пролегает указанная связь. Показал, как он выглядит физически. Как в него встроена процедура.
Таким образом, теперь мы знаем, что РП предназначен для выполнения функции. Знаем, как он устроен. И ведаем, что в нём генерируются эпизодические задачи и действия, и аккумулируются сведения и статистическая информация об их выполнении и исполнении.
Сейчас возникает вопрос: как обеспечивается воспроизводимое выполнение функции Реестром процедур? Как фактически происходит, осуществляется такое выполнение?
Без ответа на этот вопрос мы не сможем понять значение Реестра процедур для управления потоком задач. И в первую очередь для управления процессными задачами.
Ответ позволит нам осознать, что без РП невозможно в принципе это сделать. Ведь Реестр процедур – это главный рабочий орган системы УПЗ. Без него мы не сможем даже оценить, находится ли управление потоком задач (то бишь менеджмент) в состоянии статистической управляемости и воспроизводимости.
А соответственно без РП мы не сможем удостоверяться, насколько эффективно мы управляем. Будем ощущать это только на уровне интуиции. А интуиция часто обманчива.
Чтобы этого не происходило, и был изобретён РП.
Вся Технология управления задачами (ТУЗ) базируется на применении Реестров процедур. И поэтому надо понять, как РП выполняют функции?
Итак, приступим.
На самом деле ответ кроется уже в самом определении «функции», приведённом в начале настоящей статьи. Там есть фраза: «…путём воспроизводимого выполнения одной и той же процедуры, запускаемой многократно, регулярно, раз от раза, эпизодически и выполняемой итерационно в отношении каждого вновь появившегося конкретного процессного объекта (КПО) контекстной процессной сущности (ПС)».
Из этой фразы вытекает, что Реестр процедур выполняет функцию, являющуюся дискретной задачей, путём многократного (итерационного) запуска и повторения одной и той же процедуры, являющейся эпизодической задачей, в отношении каждого нового КПО контекстной ПС[2]. Такт за тактом, цикл за циклом.
После того, как РП создан, он начинает функционировать (то есть выполнять функцию). Это происходит следующим образом.
Эпизодически происходит одно и то же стандартное запускающее событие (ЗС). Оно внутри ПС порождает КПО, в отношении которого надо выполнить процедуру. То есть эта ПС становится контекстной для порождённых внутри её КПО.
Мы вносим вновь появившийся КПО в новую строку раздела «Атрибуты ПС» Реестра процедур. Выполняем в отношении него эпизодические действия из процедуры, связанные с внесением первоначальных конкретных значений его атрибутов.
Отмечаем выполнение этих действий в строке КПО в разделе «Процедура» Реестра процедур.
Получаем в секторе «КПО» Реестра процедур идентификационный индекс КПО[3] и запускаем выполнение в отношении его стандартной процедуры.
При этом в рамках процедуры запускаются:
- сама процедура в качестве запоточенной эпизодической задачи (ЗЭЗ). В этом случае процедура становится запоточенной процедурой (ЗП).
- операции из процедуры в качестве запоточенных эпизодических задач (ЗЭЗ). Эти операции становятся запоточенными операциями (ЗО).
- шаблонные эпизодические действия (ШЭД) в качестве исполняемых эпизодических действий (ЭД)
В рамках этого запуска в разделе «ЗЭЗ функции» Реестра процедур:
- производится транскрипция (считывание) ШЭЗ из сектора «ШЭЗ» Реестра процедур, в ходе чего из ШЭЗ берутся необходимые стандартные атрибуты: наименование задачи, ЦРЗ, ФР заказчика задачи, ФР ответственного выполнителя задачи, стандартные длительности;
- после транскрипции ШЭЗ производится репликация из них ЗЭЗ. Реплицируется одна ЗЭЗ в виде «запоточенной процедуры (ЗП)» и несколько ЗЭЗ в виде последовательно выполняемых «запоточенных операций (ЗО)».
- при этом каждая ЗЭЗ создаётся копированием ШЭЗ и добавлением в неё идентификационного индекса КПО.
- после создания ЗЭЗ на них назначаются: конкретные их заказчики и конкретные их ответственные выполнители. При этом указываются должности и ФИО, и соблюдается принцип «петли ответственности».
- сгенерированные таким образом ЗЭЗ из Реестра процедур в дальнейшем «транспортируются» в РП по ЗЭЗ в субсистему ВЗЗ – в адрес конкретных сотрудников – ответственных выполнителей и заказчиков задач. В результате происходит «трансляция» ЗЭЗ сотрудникам.
- в субсистеме ВЗЗ сгенерированные таким образом ЗЭЗ выполняются в рамках общего потока задач[4].
Одновременно с запуском ЗЭЗ в разделе «Процедура» Реестра процедур стартуется выполнение эпизодических действий процедуры в отношении созданного КПО:
- производится транскрипция (считывание) первой ШЭД из шапки раздела «Процедура» Реестра процедур, в ходе чего из ШЭД берутся необходимые стандартные атрибуты: наименование ШЭД, ФР заказчика ШЭД, ФР ответственного исполнителя ШЭД, трудоёмкость;
- после транскрипции первой ШЭД производится репликация из неё первого эпизодического действия (ЭД) процедуры.
- при этом первое ЭД создаётся копированием ШЭД и добавлением в неё идентификационного индекса КПО.
- заметьте, в этом случае у ЭД всё как у ЗЭЗ. Это потому, что ЭД – это производная от ЗЭЗ. ЗЭЗ выполняются путём исполнения их ЭД.
- в то же время, в отличие от ЗЭЗ, в Реестре процедур в разделе «Процедура» сгенерированное первое ЭД не отображается, а сразу же заносится («транспортируется») в РП по ЭД в субсистему ВЗЗ.
- вместо этого в разделе «Процедура» Реестра процедур в каждой ячейке таблицы на пересечении строк и столбцов указываются состояния ЭД: статус исполнения ЭД и фактическая трудоёмкость.
- само ЭД в РП по ЭД в субсистеме ВЗЗ по определённой процедуре доделывается. В рамках чего, как минимум назначаются: заказчик ЭД и его ответственный исполнитель. Указываются их должности и ФИО. Соблюдается принцип «петли ответственности».
- по результатам этой процедуры ЭД превращается в «Исполняемое действие (ИД)» и попадает в РП по ИД. В результате осуществляется «трансляция» ЭД сотрудникам для исполнения.
- в субсистеме ВЗЗ сгенерированное в Реестре процедур первое ЭД исполняется в рамках общего потока исполняемых действий.
- после того, как оно исполнено, по описанной выше схеме стартуется исполнение следующего ЭД в процедуре. Цикл повторяется. И так от одного ЭД к другому. Итерация за итерацией. С начала процедуры до конца. До последнего ЭД в процедуре. Слева направо. До тех пор, пока процедура не будет выполнена полностью.
- при этом исполнение каждого ЭД процедуры отмечается в разделе «Процедура» Реестра процедур, путём проставления в каждой ячейке таблицы на пересечении строк и столбцов состояния ЭД: статуса исполнения ЭД (а именно фактической даты исполнения ЭД) и фактической трудоёмкости.
- эти отметки в разделе «Процедура» Реестра процедур формируют исходные сведения для раздела «РИД по ФУНКЦИИ» и определяют фактические даты и трудоёмкости выполнения ЗЭЗ, сгенерированных в разделе «ЗЭЗ функции» Реестра процедур[5].
Из сказанного следует, что каждая операция процедуры в отношении КПО выполняется путём исполнения её эпизодических действий.
Дата исполнения последнего ЭД в операции определяет её срок выполнения. Совокупная трудоёмкость всех исполненных ЭД определяет фактическую трудоёмкость выполнения операции. И так в процедуре операция за операцией.
Аналогично и вся процедура в целом.
Она также выполняется путём исполнения её ЭД. Дата исполнения последнего ЭД в процедуре определяет срок её выполнения. Совокупная трудоёмкость всех исполненных ЭД определяет фактическую трудоёмкость выполнения всей процедуры.
Всё вышеописанное происходит с запоточенными эпизодическими задачами (ЗЭЗ) и эпизодическими действиями (ЭД) в Реестре процедур в отношении любого и каждого КПО, появившегося в ответ на наступление каждого запускающего события (ЗС). Вновь и вновь.
Наступило ЗС, создали КПО в РП, запустили процедуру, а в рамках её – операции и ЭД. Выполнили. Снова наступило ЗС – снова повторили это. Наступило ЗС десять раз, повторили это десять раз. Сто раз – сто раз. Наступили они одновременно – сделали всё это одновременно.
Всё это повторится столько раз, сколько раз наступит ЗС. Многократно. Сколько при этом КПО появится столько процедур и её операций, и их эпизодических действий выполнится в отношении каждого КПО.
Независимо от количества КПО всё будет повторяться и итерационно выполняться. Итерация за итерацией.
Каждая итерация – это, по сути, такт, работы Реестра процедур. Частота этих тактов возрастает с ростом количества наступивших ЗС и спадает с его уменьшением.
При росте количества наступивших ЗС нагрузка на РП растёт. При снижении – падает.
Процедуры в отношении множества КПО могут стартоваться одновременно, выполняться параллельно, а завершаться в разные сроки. Их может быть очень много.
Могут возникать задержки в выполнении процедур в отношении каких-либо КПО.
И понятно, что надо стремиться к тому, чтобы в СРЕДНЕМ они выполнялись ритмично: с заданной длительностью и трудоёмкостью. Так, чтобы обеспечивалась статистическая управляемость и воспроизводимость выполнения функции. Ведь своевременное и ритмичное выполнение процедур, будет приводить к воспроизводимому выполнению функции Реестром процедур.
Можно ли считать, что какой-то узел работает ритмично, хорошо и исправно, если он один такт делает, допустим, за 10 дней, другой – за 20 дней, третий – за 15 дней, четвёртый – за 2 дня? В то время как предполагалось, что он будет это делать каждый раз за 3 дня.
Думаю, что нет. Мы будем говорить, что это плохая работа узла.
Представьте себе, что в двигателе внутреннего сгорания (ДВС) для того, чтобы выдать 1000 оборотов в минуту, поршень должен делать каждый такт ритмично с длительностью 0,06 секунды. А если он будет один такт делать 5 секунд, второй – 20 секунд, третий - 0,3 секунды, четвёртый - 0,01 секунду. Сможет ли он выдать нужный результат и мощность? Сможет ли ДВС выдержать такую не ритмичную нагрузку? Обеспечит ли нужный отклик при нажатии на педаль газа водителем авто? Ответ очевиден.
То же самое должно быть и в интеллектуальном труде.
Только встаёт проблема, как замерить это в интеллектуальном труде? Где всё абстрактно и не осязаемо, не материально.
Как в интеллектуальном труде понять, выполняем ли мы процедуры ритмично? Находится ли их выполнение в статистически управляемом состоянии? Обеспечивается ли при этом воспроизводимость выполнения функции? Ведь нельзя же управлять тем, что невозможно оценить и измерить.
Для того чтобы понять это, нужно собирать и оценивать соответствующую статистику по всему описанному выше множеству КПО.
А как это сделать?
Мой ответ: только путём применения Реестра процедур в тех ипостасях и форматах, которые я описал для него в настоящем блоге выше.
И в Реестре процедур с описанной выше целью сбор исходных статистических данных осуществляется в разделе «РИД по ФУНКЦИИ». Делается это в режиме реального времени в отношении каждого КПО и каждой запущенной процедуры и совокупно по всем КПО и процедурам.
В нём формируются необходимые исходные статистические данные в виде статистических рядов. Эти данные рассчитываются, определяются накапливаются в «РИД по ФУНКЦИИ» Реестра процедур исходя из исходных сведений, которые формируются в разделе «Процедура» и в разделе «ЗЭЗ функции» Реестра процедур.
По ним можно оценивать статистическую управляемость и воспроизводимость выполнения функции, а затем бизнес-процессов и миссии в целом.
Их уже можно анализировать и оценивать. По ним можно выполнять группировку, сортировку и фильтрацию, выявлять тренды (закономерности) и вариации, вычислять контрольные пределы и допуски, рассчитывать итоговые и промежуточные, а также среднестатистические значения и делать многое другое.
То есть их можно крутить и вертеть, как вздумается. Что, собственно говоря, и производится в последующем в РОС по ПЦР миссии[6], куда накопленные данные и передаются.
По результатам анализа статистики можно делать выводы и оценки о работоспособности Реестра процедур, той или иной системы в целом и её субсистем, вырабатывать корректирующие и регулирующие мероприятия. Производить совершенствования Реестров процедур путём их правки[7].
При этом указанные анализ и оценка производятся в рамках процедур по оценке степени достижения показателей целевых результатов (ОСД ПЦР) в РОС по ПЦР миссии.
Там мы выявляем, удаётся ли нам действительно обеспечивать статистическую управляемость и воспроизводимость выполнения процедур, в рамках выполнения функции.
Если у нас получается добиться этого на протяжении каждого дискретного периода, тогда функция, выполняемая Реестром процедур, будет воспроизводимой.
Если функция выполняется воспроизводимо, значит, мы можем судить и быть уверенными, что РП работает исправно.
Получается, что РП многократно (итерационно) запускает одну и ту же процедуру и выполняет все запоточенные процедуры ритмично: с заданной длительностью и трудоёмкость, так, чтобы обеспечивалась статистическая управляемость и воспроизводимость выполнения функции.
И так с каждым Реестром процедур по каждой функции.
Подытожим сказанное.
РП выполняет функцию, являющуюся дискретной задачей, путём многократного (итерационного) запуска и повторения одной и той же процедуры, являющейся эпизодической задачей, в отношении каждого нового КПО контекстной ПС. Наступило ЗС, создали КПО в РП, запустили процедуру, а в рамках её – операции и ЭД. Выполнили. Снова наступило ЗС – снова повторили это. Наступило ЗС десять раз, повторили это десять раз. Сто раз – сто раз. Наступили они одновременно – сделали это одновременно. Всё повторится столько раз, сколько раз наступит ЗС. Многократно. Сколько при этом КПО появится столько процедур и её операций, и их эпизодических действий выполнится в отношении каждого КПО. При росте количества наступивших ЗС нагрузка на РП растёт. При снижении – падает. При этом надо стремиться к тому, чтобы в СРЕДНЕМ всё выполнялось ритмично: с заданной длительностью и трудоёмкостью. Так, чтобы обеспечивалась статистическая управляемость и воспроизводимость выполнения функции. Ведь своевременное и ритмичное выполнение процедур, будет приводить к воспроизводимому выполнению функции Реестром процедур. В самом РП выявляется, удаётся ли нам действительно это сделать. Если у нас получается добиться этого на протяжении каждого дискретного периода, тогда функция, выполняемая Реестром процедур, будет воспроизводимой. Если функция выполняется воспроизводимо, значит, мы можем судить и быть уверенными, что РП работает исправно.
При этом:
- если все РП в субсистеме работают исправно, то есть воспроизводимо выполняют функции, тогда субсистема воспроизводимо выполняет свой бизнес-процесс, то есть работает исправно.
- если все субсистемы в системе работают исправно, то есть воспроизводимо выполняют свои БП, тогда вся система воспроизводимо выполняет свою миссию, то есть работает исправно.
- если все миссии всех систем организации[8] выполняются воспроизводимо, значит, организация работает исправно.
Далее я предлагаю завершить описание Реестра процедур обзором его роли в управлении потоком задач. Давайте ответим на вопрос: какова роль Реестра процедур в управлении потоком задач?
Полная версия статьи доступна в моей книге «ЗАДАЧИ ЧУДЕСНЫЕ, ИЛИ КОЗЫРНАЯ «ТУЗ» МОТАЕВА!»
С уважением к Вам и Вашему делу, Мотаев Александр
Обсудить эту и другие статьи блога вы можете в нашем Telegram-канале "Управление потоком задач".
[1] Процедура - Это ШЭЗ, имеющая расчётную плановую длительность и расчётную плановую трудоёмкость, состоящая из набора алгоритмизированных операций и набора алгоритмизированных ШЭД, выполняемых последовательно по набору определённых правил и применяющих набор определённых понятий, формуляров и хранилищ информации (ХИ). Описывается ниже в статье «Понятие сущности «ПРОЦЕДУРА» в разделе 7. «Технология управления задачами (ТУЗ)».
[2] О КПО и ПС читай статью «Понятие «сущность» выше в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
[3] Как это делается, я рассматривал выше в статье «Раздел «Атрибуты ПС» Типового Реестра Процедур» в настоящем разделе.
[4] Всю схему генерирования ЗЭЗ я подробно расписывал выше в статье «Раздел «ЗЭЗ функции» Типового Реестра Процедур» в настоящем разделе.
[5] Всю схему генерирования эпизодических действий (ЭД) я подробно расписывал выше в статье «Раздел «Процедура» Типового Реестра Процедур» в настоящем разделе.
[6] Читай о нём в статье «Реестр оценки статистики по ПЦР миссии» в разделе 6. «Система управления потоком задач (Система УПЗ)».
[7] Об этом я говорил выше в статье «РИД по ФУНКЦИИ» Типового Реестра Процедур» в настоящем разделе.
[8] А мы помним, что организация – это полисистема, то есть множество (набор) систем. Смотри статью «Организация – это …» выше в разделе 1. «Введение в управление потоком задач».