Дела да случаи совсем замучили
В предыдущей статье «Какая технология нужна для управления потоком задач?» я, по сути, обозначил, что ТУЗ – это совокупность (набор) алгоритмов (последовательностей) выполнения: шаблонных эпизодических задач (процедур, операций) – для управления потоком задач с целью обеспечения наивысшей ПИТ.
Тем самым я ввёл в единый язык УПЗ новую сущность – шаблонную эпизодическую задачу (кратко – ШЭЗ).
Встаёт вопрос: что такое шаблонная эпизодическая задача (ШЭЗ)?
Так как это основной объект, которым оперирует технология, то надо его описать. Дать чёткое понятие этой сущности. Чтобы в дальнейшем её можно было идентифицировать и отделить от других сущностей управления потоком задач.
Чтобы ей можно было оперировать. Чтобы Реестр процедур по моделированию шаблонных эпизодических задач (кратко – РП по ШЭЗ) мог воспроизводимо выполнять функцию в отношении этой сущности.
Чтобы в нём мы могли выявлять все конкретные процессные объекты (КПО), относящиеся к этой контекстной процессной сущности, и оперировать этими КПО по мере их появления – эпизодически.
По сложившемуся алгоритму, сначала дадим определение.
Шаблонная эпизодическая задача (ШЭЗ) — это шаблон (паттерн, образец, трафарет, «рыба»), то есть это стандартизированное описание атрибутов какой-либо эпизодической задачи, по которому в отношении конкретного процессного объекта (КПО) генерируется (создаётся, клонируется, запускается) запоточенная эпизодическая задача (ЗЭЗ) из-за наступления заданного запускающего события (ЗС), для реакции на это ЗС путём её выполнения в срок, рассчитанный в момент создания ЗЭЗ, исходя из стандартной длительности ШЭЗ.
Разберём это определение по частям. И по традиции начнём с выяснения, что такое эпизодическая задача (ЭЗ).
Ранее в статье «Поток задач» в разделе 4 я указал, что ШЭЗ является подвидом процессной задачи. Дал следующее определение процессной задаче: «Процессная задача (ПЗ)[1] – это многоразовая задача из среды «процессы», повторяющаяся регулярно: дискретно или эпизодически; рождающаяся в ходе поиска варианта воздействия на объект системой (либо её субсистемой, либо её реестром процедур); представляющая собой выбранный вариант воздействия на объект, которым является: (1) либо какая-то абстрактная сущность (АС), (2) либо какая-то процессная сущность (ПС), (3) либо какой-то конкретный процессный объект (КПО); направленная на достижение стандартизированного предсказуемого и чётко определённого целевого результата – одного и того же при каждом повторении задачи; выполняемая с полной определённостью: (1) в составе декомпозированных процессных задач или процессных действий нижнего уровня, (2) в их логической цепочке причинно-следственных связей, (3) в длительности, в сроке и трудоёмкости её выполнения».
Затем в статье «Процессная задача (ПЗ)» выше в разделе 6 я подробно расписал такую абстрактную сущность, как «процессная задача (ПЗ)», где упоминал такую её разновидность, как «эпизодическая задача (ЭЗ)».
Эпизодическая задача (ЭЗ) – это процессная задача, которая обеспечивает удовлетворение разовой потребности – необходимости; представляющая собой выбранный вариант воздействия на объект, которым является: конкретный процессный объект (КПО) контекстной процессной сущности; которая повторяется, возобновляется раз от раза – эпизодически, при наступлении одного и того же запускающего события (ЗС), порождающего эту необходимость в отношении разных КПО, и которая оценивается сразу же после своего выполнения - без привязки к какому-либо дискретному периоду, т.е. тоже эпизодически.
Ранее в статье «Чем порождается задача?» выше в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА» я написал, что: «задача порождается проблемой (от греч. problema — преграда, трудность, препятствие), то есть встречей с сопротивлением, препятствием, преградой, трудностью».
Затем в том же разделе в статье «Понятие «проблема» я разъяснил, что такое проблема, в том числе, что такое разовая проблема в виде изъяна.
Там я рассказал, что поиск способа преодоления проблемы всегда начинается с формулирования потребности[2], которую она порождает. В дальнейшем из потребности формулируется задача, выполнение которой обеспечивает её удовлетворение. Указал, что изъян порождает потребность в виде «необходимости».
Необходимость – это разовая потребность, объективно возникшая из-за столкновения с изъяном; требующая удовлетворения путём выполнения известной разовой задачи, выполнение которой приведёт к преодолению изъяна и к выполнению которой можно приступить непосредственно и немедленно.
Что означает, если разовая задача известна, нам необходимо лишь её выполнить. То есть имеется всего лишь необходимость действовать.
Но из статьи «Поток задач»[3] мы знаем, что разовая задача – это целевая задача, а процессная задача – это всегда многоразовая задача[4]. В то же время только что я сказал, что эпизодическая задача (ЭЗ) – это процессная, а, следовательно, многоразовая задача. При этом я указал, что она обеспечивает удовлетворение разовой потребности в виде необходимости, которую можно удовлетворить выполнением только разовой задачи.
Вроде как обозначилась некоторая нестыковка - коллизия. С одной стороны разовая, а с другой – многоразовая.
На самом деле коллизии нет, так как речь идёт о разных конкретных процессных объектах (КПО) одной и той же контекстной процессной сущности (ПС).
Как я сказал, КПО является объектом воздействия, когда выполняется эпизодическая задача. То есть эпизодическая задача всегда выполняется в отношении КПО. Её выполнением меняется положение и/или состояние какого-то конкретного процессного объекта. При этом эпизодическая задача в отношении одного КПО всегда выполняется разово. То есть как бы разовая.
В то же время многоразовость и повторяемость эпизодической задачи выражается в том, что она – одна и та же много раз повторяется в отношении разных КПО, относящихся к одной и той же контекстной процессной сущности (ПС). То есть одна и та же эпизодическая задача выполняется в отношении сначала одного КПО, потом – второго, потом – третьего. И так бесконечно. Главное, чтобы эти КПО относились к одной и той же контекстной процессной сущности (ПС).
Например, эпизодическая задача: «Заключить договор» будет повторяться много раз – одна и та же в отношении разных конкретных договоров с разными контрагентами.
При этом «договор» будет контекстной процессной сущностью (ПС) для всех конкретных договоров. Значит её конкретными процессными объектами (КПО) будут конкретные разновидности и формы договоров с конкретными контрагентами по конкретным предметам договоров с конкретными датами и сроками, правами и обязательствами.
И в отношении каждого такого договора будет выполняться одна и та же эпизодическая задача: «Заключить договор». Много раз, столько раз, сколько конкретных договоров появится. При этом в отношении каждого конкретного договора эта ЭЗ будет выполняться всегда только один раз.
В то же время эпизодическая задача (ЭЗ), как процессная задача, будет стандартизированной и будет стартоваться (запускаться) регулярно, раз от раза повторяющимся эпизодически[5], стандартным запускающим событием (кратко – ЗС)
Где запускающее событие (ЗС)[6] – это спонтанно случившееся наступившее обстоятельство (создавшаяся ситуация или состоявшийся существенный факт), локализованное во времени и пространстве; относящееся к положению и/или состоянию какого-то конкретного процессного объекта (КПО); порождающее разовую проблему в виде изъяна, вызывающего в свою очередь разовую потребность – необходимость, которая требует незамедлительной реакции по её удовлетворению; вследствие чего запускающее выполнение набора определённых эпизодических задач (ЭЗ) в отношении КПО, т. е. - это событие (обстоятельство, ситуация, факт) эпизодически запускающее (инициирующее, стартующее) генерирование определённой эпизодической задачи (ЭЗ) в отношении определённого КПО.
Для каждой эпизодической задачи должно быть определено и стандартизировано ЗС, наступление которого будет стартовать её выполнение.
Например, для эпизодической задачи: «Заключить договор» будет определено запускающее событие: «Получено согласие контрагента на сделку».
Наступление заранее определённого, стандартного ЗС породит стандартную разовую проблему, которая вызовет разовую потребность в виде необходимости, которую, в свою очередь, потребуется незамедлительно удовлетворить путём выполнения стандартной эпизодической задачи, привязанной к наступившему ЗС.
Например, при наступлении стандартного ЗС: «Получено согласие контрагента на сделку» появится разовая проблема: «Отсутствует юридически оформленное согласие контрагента на сделку» (которое официально защитит наши интересы). Эта проблема породит такую разовую потребность, как: «Необходимость в заключении договора по сделке».
Удовлетворить эту потребность мы должны немедленно путём выполнения эпизодической задачи: «Заключить договор». Её мы запустим при наступлении ЗС: «Получено согласие контрагента на сделку».
И такая логика будет действовать каждый раз, когда будет наступать одно и то же ЗС: «Получено согласие контрагента на сделку» с каждым контрагентом по каждой сделке.
Отсюда, одна и та же эпизодическая задача будет повторяться, возобновляться раз от раза – эпизодически, при наступлении одного и того же запускающего события (ЗС), порождающего необходимость в отношении разных КПО.
Таким образом, эпизодическая задача жёстко привязана к наступлению запускающего события (ЗС). ЗС наступило, эпизодическая задача в отношении нового КПО запустилась. И так по каждому ЗС в отношении каждого КПО. От одного ЗС к другому, от одного КПО к другому. Непрерывно. Но эпизодически. Это так называемая «управляемая событиями цепь процессов» (Event-driven Process Chain – EPC)[7].
При этом надо понимать, что ЗС случается не ритмично, не дискретно, не по событию тайминга, не при наступлении какой-то даты начала дискретного периода, а спонтанно[8], случайно, хаотически, беспорядочно, т. е. когда вздумается, ситуативно, по мере появления потребности – эпизодически[9].
Поэтому и задача, обеспечивающая реакцию на ЗС, эпизодическая.
При этом надо учитывать, что изъян всегда характеризуется качественным состоянием или положением какого-то известного объекта: есть/нет; наличествует/отсутствует; работает/не работает; создана/не создана, выполнено/не выполнено и т. д.
Это означает, что и разовая потребность в виде необходимости, и сама эпизодическая задача по её удовлетворению всегда будут характеризоваться качественным состоянием или положением какого-то конкретного процессного объекта (КПО).
Следовательно, целевой результат эпизодической задачи – всегда качественный.
Сказанное, а также то, что эпизодическая задача – это процессная задача, значит, что формулировка целевого результата эпизодической задачи при каждом её повторении – будет одна и та же, универсальная. Стандартная. Однажды сформулированная и используемая регулярно – при каждом повторении задачи.
В отношении каждого нового КПО одной и той же контекстной процессной сущности (ПС) будет этот стандартизированный предсказуемый и чётко определённый целевой результат. Один и тот же при каждом повторении задачи.
Например, для эпизодической задачи: «Заключить договор» целевой результат может быть таким: «Один экземпляр подписанного с двух сторон оригинала договора помещён в архив договоров организации». И этот ЦРЗ будет одним и тем же в отношении любого заключаемого в организации конкретного договора по конкретной сделке.
Шаблонная эпизодическая задача (ШЭЗ) — это шаблон (паттерн, образец, трафарет, «рыба»), то есть это стандартизированное описание атрибутов какой-либо эпизодической задачи.
Эпизодическая задача, как и дискретная задача, является процессной задачей. А раз это процессная задача, то значит, она является многоразовой задачей, повторяющейся регулярно. То есть её надо выполнять каждый раз, когда наступает определённая ситуация.
Соответственно одну и ту же эпизодическую задачу надо формулировать много раз. И если они повторяются очень часто, то это делать надо также очень часто.
На формулирование задач тратится время. То есть с возрастанием частоты формулирования эпизодической задачи, возрастает и объём трудозатрат на её формулирование. Возникает вопрос, зачем каждый раз формулировать практически одно и то же и тратить на это время, когда можно создать шаблон, по которому затем создавать конкретные запоточенные эпизодические задачи.
ШЭЗ, по сути, и есть такой шаблон. Поэтому и «шаблонная».
Это своего рода, заранее проработанная, стандартизированная «рыба» — заготовка эпизодической задачи. Шаблон, представляющий собой стандартизированное описание атрибутов какой-либо эпизодической задачи. То есть, мы заранее описываем все атрибуты какой-то эпизодической задачи, делаем её шаблон.
По аналогии с «рыбой» договора. Когда под какие-то регулярные коммерческие сделки по заданному предмету, например, по поставке электрической энергии, юристами заранее разрабатывается «рыба» договора (типовая форма договора), например, договора энергоснабжения.
При этом юристы учитывают все возможные риски и обязательства сторон. Основываясь на нормативно-правовых актах и сложившейся судебной практике, а также опыте, накопленном за предыдущие годы работы с потребителями электрической энергии.
Эта «рыба» затем используется договорниками для заключения уже конкретных сделок с конкретными потребителями электроэнергии. То есть договорники, каждый раз не разрабатывают под каждую сделку текст договора, они берут готовую «рыбу» договора энергоснабжения, разработанную юристами заранее, заполняют её значениями атрибутов, касающимися конкретного потребителя электроэнергии, и предлагают ему к заключению.
Ниже пример шаблонной эпизодической задачи – пример стандартизированного описания атрибутов эпизодической задачи по конструированию Реестра процедур.
Таблица "Пример шаблонной эпизодической задачи (ШЭЗ)"
Шаблонная эпизодическая задача (ШЭЗ) — это шаблон, по которому генерируется (создаётся, клонируется, запускается) запоточенная эпизодическая задача (ЗЭЗ).
Если ШЭЗ была смоделирована заранее, то по ней при наступлении определённой ситуации, генерируется запоточенная эпизодическая задача (ЗЭЗ)[10]. То есть та эпизодическая задача, которая сгенерирована и включена в текущий поток задач, то бишь эпизодическая задача готовая и принятая к выполнению.
По сути, из ШЭЗ создаётся клонированием и запускается отдельная конкретная ЗЭЗ. Таким образом ШЭЗ превращается в ЗЭЗ.
В ходе такого клонирования ШЭЗ, как заготовка, подвергается небольшой обработке. В неё добавляется конкретика. Конкретика касается объекта, в отношении которого выполняется эпизодическая задача. Этим объектом является КПО – конкретный процессный объект.
Когда из ШЭЗ создаётся и запускается (генерируется) ЗЭЗ, в неё добавляется комбинация значений атрибутов КПО – идентификационный индекс КПО[11], в отношении которого выполняется запускаемая эпизодическая задача. То есть ЗЭЗ отличается от ШЭЗ набором значений атрибутов КПО - идентификационным индексом КПО, в отношении которого она выполняется.
Из одной ШЭЗ может быть создано неограниченное количество ЗЭЗ, столько сколько появится КПО, на которые или в отношении которых нужно осуществить воздействие. То есть количество ЗЭЗ прямо пропорционально количеству КПО. А ШЭЗ при этом всегда одна и та же.
В то же время ЗЭЗ будут отличаться друг от друга комбинациями значений атрибутов КПО. Ведь у каждого КПО свой уникальный набор значений атрибутов. И по этому набору ЗЭЗ будут отличаться друг от друга.
Если вернуться к примеру с «рыбой» договора энергоснабжения, то из одной «рыбы» может быть создано множество конкретных договоров энергоснабжения с конкретными потребителями электроэнергии. Столько, сколько будет таких потребителей. При этом «рыба» договора энергоснабжения всегда будет одна и та же. А конкретные договоры энергоснабжения будут отличаться друг от друга набором параметров (реквизитов), присущих конкретным потребителям.
Ниже приведены примеры ЗЭЗ, созданных из одной и той же ШЭЗ, приведённой выше в настоящей статье.
Таблица "Примеры ЗЭЗ, сгенерированных из ШЭЗ по конструированию Реестра процедур"
Запоточенная эпизодическая задача (ЗЭЗ) генерируется (создаётся, клонируется, запускается) из ШЭЗ из-за наступления заданного запускающего события (ЗС).
Определённой ситуацией, при наступлении которой создаётся (запускается) ЗЭЗ из ШЭЗ, является происхождение запускающего события (ЗС).
То есть ЗЭЗ создаётся из ШЭЗ, когда случается определённое чётко заданное событие. Его наступление инициирует генерирование ЗЭЗ из ШЭЗ.
Это ЗС задаётся заранее, одновременно с моделированием ШЭЗ. То есть мы заранее знаем при наступлении, какого события, какую ШЭЗ мы должны взять и какую ЗЭЗ мы должны из неё сгенерировать (запустить). Остаётся лишь отслеживать наступление всех заданных запускающих событий. И при их обнаружении, из нужной ШЭЗ генерировать необходимую ЗЭЗ в отношении заданного КПО.
Ведь, если вы посмотрите на определение ЗС, то оно всегда относится к положению и/или состоянию какого-то конкретного процессного объекта (КПО). Это означает, что нужное нам событие всегда случается с каким-то КПО или в отношении какого-то КПО. А эпизодическая задача выполняется всегда в отношении или с КПО. Ведь любая задача объектна. И объектом воздействия в эпизодической задаче всегда выступает КПО.
Например, для приведённой выше ШЭЗ в таблице «Пример шаблонной эпизодической задачи (ШЭЗ)» заданным ЗС является следующее событие: «сформирована функция, выполняемая реестром процедур» (см. строку 9 таблицы).
При его наступлении из указанной выше ШЭЗ были созданы ЗЭЗ, также указанные выше в таблице «Примеры ЗЭЗ, сгенерированных из ШЭЗ по конструированию РП».
Это говорит о том, что после того, как была сформирована функция, выполняемая конкретным реестром процедур, мы приступаем к конструированию самого реестра процедур. И так по каждому РП.
Запоточенная эпизодическая задача (ЗЭЗ) генерируется (создаётся, клонируется, запускается) из ШЭЗ для реакции на ЗС путём её выполнения в срок, рассчитанный в момент создания ЗЭЗ, исходя из стандартной длительности ШЭЗ.
При моделировании ШЭЗ, в обязательном порядке должен определяться такой её обязательный атрибут, как «Плановая длительность ШЭЗ», измеряемая в днях.
Эта длительность используется для расчёта срока выполнения ЗЭЗ, генерируемой из ШЭЗ.
Расчёт срока выполнения ЗЭЗ осуществляется от даты генерации (даты запуска) ЗЭЗ. В процессе генерации ЗЭЗ.
В идеале дата генерации ЗЭЗ из ШЭЗ должна совпадать с датой, в которую случается ЗС. Но в жизни часто бывает, что мы запаздываем за событием. То есть событие может случиться, а мы можем на него отреагировать только через несколько дней.
Поэтому срок выполнения ЗЭЗ (дата) должен рассчитываться путём прибавления «плановой длительности ШЭЗ» именно к дате генерации (запуска) ЗЭЗ. При этом, конечно же, должны учитываться выходные и праздничные дни.
Срок выполнения ЗЭЗ является обязательным атрибутом. Об этом мы говорили в статье «Что такое задача?» выше в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА». Без срока задача – не задача.
ЗЭЗ, запущенная из ШЭЗ, — это то, что мы должны выполнить в установленный срок, чтобы правильно и адекватно среагировать на случившееся ЗС. То есть она предполагает заданный вариант воздействия на КПО, который мы должны осуществить, чтобы изменить положение и/или состояние КПО с одного на другое. Перевести КПО в желаемое положение и/или состояние.
Причём новое положение и/или состояние КПО, полученное в результате выполнения сгенерированной ЗЭЗ, может являться запускающим событием для генерирования следующей ЗЭЗ из следующей ШЭЗ в отношении нового КПО.
Приведу пример. Допустим, случается заданное ЗС: «поступил запрос клиента на услугу». Это ЗС инициирует генерирование ЗЭЗ из ШЭЗ: «Заключить с клиентом договор на услугу».
Выполнение ЗЭЗ, созданной из этой ШЭЗ, – это адекватная и желаемая реакция на случившееся ЗС: «поступил запрос клиента на услугу». Эта ЗЭЗ выполняется в отношении КПО: «конкретного договора с конкретным клиентом на конкретную услугу».
В результате выполнения этой ЗЭЗ у нас меняется положение и/или состояние этого КПО. До наступления ЗС, у нас не было такого КПО, в ходе выполнения ЗЭЗ мы его создали и заключили. То есть по результату выполнения ЗЭЗ мы получили следующее положение и состояние КПО: «конкретный договор с конкретным клиентом на конкретную услугу подписан с двух сторон, вступил в силу, помещён в архив».
Что это означает? А то, что полученное положение и состояние КПО является запускающим событием для следующей в цепи ЗЭЗ из такой следующей ШЭЗ, как: «Выполнить заказ клиента на услугу».
Выполнение новой ЗЭЗ, созданной уже из этой ШЭЗ, – это адекватная и желаемая реакция на ЗС: «конкретный договор с конкретным клиентом на конкретную услугу подписан с двух сторон, вступил в силу, помещён в архив». Теперь надо выполнить обязательства по этому договору – выполнить заказ.
Новая ЗЭЗ в цепи выполняется в отношении другого – следующего КПО: «заказа конкретного клиента на конкретную услугу».
В результате выполнения этой ЗЭЗ у нас меняется положение и/или состояние этого нового КПО. До наступления ЗС, у нас не было такого КПО, в ходе выполнения ЗЭЗ мы его создали и выполнили.
То есть по результату выполнения ЗЭЗ мы получили следующее положение и состояние нового КПО: «заказ выполнен путём исполнения всех обязательств по договору, расчёты по договору произведены в полном объёме».
Так можно продолжать дальше. Например, выполнение заказа может инициировать задачу по публикации новости на сайте об успешном выполнении очередного заказа; задачу по пополнению (обновлению) референс-листа на сайте и в бумаге; задачу по получению от клиента отзыва о работе вашей организации и т. д.
Описанное выше – это, по сути, методика «Управляемая событиями цепь процессов» (Event-driven Process Chain - EPC)»[12] в действии. То есть мы видим, что одно начальное запускающее событие инициирует выполнение не одной задачи, а целой цепи процессных задач[14].
Как правило, запускающее событие, которое инициирует выполнение цепи процессных задач, является внешним по отношению к организации. Я такое ЗС называю «входящим».
Отсюда, особенно важно отслеживать все входящие ЗС. То есть следить за тем, что «прилетает» извне. Чтобы успевать своевременно и адекватно реагировать именно на них, запуская из ШЭЗ необходимые цепи эпизодических задач. При этом внутренние запускающие события в этих цепях, должны отслеживаться руководителями с применением Реестров процедур. И в них же должен вестись контроль хода выполнения всех ЗЭЗ, сгенерированных из ШЭЗ.
А это означает также, что важно не только отслеживать все ЗС, но своевременно обеспечить моделирование всех необходимых ШЭЗ и ЗС, инициирующих генерирование ЗЭЗ, и следить за их актуальностью.
Здесь особо хотелось бы остановиться на сложности и трудоёмкости управления эпизодическими задачами. На это очень сильно влияет частота, эпизодичность, случайность, количество и не ритмичность наступления запускающих их событий.
Во-первых, это требует серьёзных усилий на контроль и отслеживание всех запускающих событий: входящих и внутренних. Чтобы оперативно на них реагировать. Особенно если их очень много, и они случаются очень часто.
Во-вторых, это вызывает не равномерность загрузки. С запускающими событиями бывает «то густо, то пусто». В один промежуток времени может случиться сразу много ЗС, которые инициируют большое количество эпизодических задач, что резко увеличит загрузку сотрудников их выполняющих. В другой период наоборот может случиться совсем мало ЗС или вообще не случиться. Тогда сотрудники окажутся существенно незагруженными.
В решении этих проблем существенно поможет АСУЗ[14]. Благодаря ей в дальнейшем руководству организации не потребуется отслеживать внутренние ЗС. Они смогут сконцентрироваться на отслеживании входящих ЗС. Отслеживать же все внутренние ЗС будет АСУЗ в автоматизированном режиме. И при наступлении внутреннего ЗС АСУЗ будет сама генерировать все необходимые ЗЭЗ из заранее смоделированных ШЭЗ.
Это исключит трудозатраты на генерирование ЗЭЗ из ШЭЗ, на отслеживание внутренних ЗС. Кроме того, в АСУЗ будет накапливаться статистика, по которой можно будет рассчитывать среднюю загрузку сотрудников эпизодическими задачами, выявлять тренды и другие закономерности в такой загрузке. Что в свою очередь позволит формировать более адекватный штат сотрудников.
«ШЭЗ» является типом, так как не имеет конкретных значений атрибутов, а только необходимый и достаточный набор их названий, по наличию которых огромное разнообразие всяких конкретных объектов относится или не относится к этому типу. Таким образом, «ШЭЗ» — это сущность.
Общее функциональное предназначение существования сущности «ШЭЗ» - обеспечить её моделированием стандартизированное описание атрибутов какой-либо эпизодической задачи.
«ШЭЗ» обладает обязательными названиями атрибутов, указанными ниже в статье «Воспроизводимое моделирование Шаблонных Эпизодических Задач (ШЭЗ)» в Разделе 7.1. «Генерирование процессных задач» в настоящем разделе.
Сущностью «ШЭЗ» является всё то, что:
- соответствует приведённому выше определению,
- выполняет указанное выше функциональное предназначение
- и имеет полный состав обязательных названий атрибутов.
Сущность «ШЭЗ» процессная, потому что объединяет не другие сущности, а неограниченное количество конкретных процессных объектов (КПО), наследующих её названия атрибутов, которым для их идентификации присваиваются уже конкретные значения атрибутов.
Подведём итог.
Эпизодическая задача (ЭЗ) – это процессная задача, которая обеспечивает удовлетворение разовой потребности – необходимости; представляющая собой выбранный вариант воздействия на объект, которым является: конкретный процессный объект (КПО) контекстной процессной сущности; которая повторяется, возобновляется раз от раза – эпизодически, при наступлении одного и того же запускающего события (ЗС), порождающего эту необходимость в отношении разных КПО, и которая оценивается сразу же после своего выполнения - без привязки к какому-либо дискретному периоду, т.е. тоже эпизодически. Эпизодическая задача (ЭЗ) в отношении одного КПО всегда выполняется разово. В то же время многоразовость и повторяемость эпизодической задачи выражается в том, что она – одна и та же много раз повторяется в отношении разных КПО, относящихся к одной и той же контекстной процессной сущности (ПС). Эпизодическая задача (ЭЗ), как процессная задача, будет стандартизированной и будет стартоваться (запускаться) регулярно, раз от раза повторяющимся эпизодически, стандартным запускающим событием (кратко – ЗС). Для каждой ЭЗ должно быть определено и стандартизировано ЗС, наступление которого будет стартовать её выполнение. ЭЗ жёстко привязана к наступлению ЗС. ЗС наступило, эпизодическая задача в отношении нового КПО запустилась. При этом надо понимать, что ЗС случается не ритмично, не дискретно, не по событию тайминга, не при наступлении какой-то даты начала дискретного периода, а спонтанно, случайно, хаотически, беспорядочно, т. е. когда вздумается, ситуативно, по мере появления потребности – эпизодически. Целевой результат эпизодической задачи – всегда качественный. Шаблонная эпизодическая задача (ШЭЗ) — это шаблон (паттерн, образец, трафарет, «рыба»), то есть это стандартизированное описание атрибутов какой-либо эпизодической задачи, по которому в отношении конкретного процессного объекта (КПО) генерируется (создаётся, клонируется, запускается) запоточенная эпизодическая задача (ЗЭЗ) из-за наступления заданного запускающего события (ЗС), для реакции на это ЗС путём её выполнения в срок, рассчитанный в момент создания ЗЭЗ, исходя из стандартной длительности ШЭЗ. Это своего рода, заранее проработанная, стандартизированная заготовка эпизодической задачи. Из ШЭЗ создаётся клонированием и запускается отдельная конкретная ЗЭЗ. Таким образом ШЭЗ превращается в ЗЭЗ. Когда из ШЭЗ создаётся и запускается (генерируется) ЗЭЗ, в неё добавляется комбинация значений атрибутов КПО, в отношении которого выполняется запускаемая эпизодическая задача. Из одной ШЭЗ может быть сгенерировано неограниченное количество ЗЭЗ, столько сколько появится КПО. ЗЭЗ создаётся из ШЭЗ, когда происходит определённое чётко заданное событие – запускающее событие (ЗС). Его наступление инициирует генерирование ЗЭЗ из ШЭЗ. ЗС задаётся заранее, одновременно с моделированием ШЭЗ. Срок выполнения ЗЭЗ (дата) рассчитывается путём прибавления «плановой длительности ШЭЗ» к дате генерации ЗЭЗ. ЗЭЗ, запущенная из ШЭЗ, — это то, что мы должны выполнить в установленный срок, чтобы правильно и адекватно среагировать на ЗС. При этом эпизодичность, случайность, частота, количество и не ритмичность наступления ЗС обуславливают сложность и трудоёмкость управления эпизодическими задачами. «ШЭЗ» — это сущность. Общее предназначение (функциональное назначение) существования сущности «ШЭЗ» - обеспечить её моделированием стандартизированное описание атрибутов какой-либо эпизодической задачи. Сущность «ШЭЗ» процессная, потому что объединяет не другие сущности, а неограниченное количество конкретных процессных объектов (КПО).
Именно эпизодические задачи занимают основную долю в потоке задач любой организации. Особенно той, где уже «устаканивается» среда «процессы». Поэтому, собственно, им необходимо уделять основное внимание при налаживании управления потоком задач.
И начинать делать это надо в первую очередь с моделирования ШЭЗ, связанных с управлением потоком задач.
Ниже в подразделах 7.1-7.3 настоящего раздела я опишу все ШЭЗ, которые нужно использовать для управления потоком задач. Совокупность которых и будет представлять собой Технологию Управления Задачами (ТУЗ).
А пока изучим, что такое процедура?
Полная версия статьи доступна в моей книге «ЗАДАЧИ ЧУДЕСНЫЕ, ИЛИ КОЗЫРНАЯ «ТУЗ» МОТАЕВА!»
С уважением к Вам и Вашему делу, Мотаев Александр
Обсудить эту и другие статьи блога вы можете в нашем Telegram-канале "Управление потоком задач".
[1] Более подробно о том, что из себя представляет процессная задача, я рассказывал в статье «Процессная задача (ПЗ)» выше в разделе 6. «Система управления потоком задач (Система УПЗ)».
[2] Потребность — это возникшее по какой-либо объективной причине, требующее удовлетворения желание, преодолеть выявленную проблему, отсюда, это всегда противоположность или противопоставление проблеме, возникающая в случае, если текущее состояние или положение объекта нас не устраивает, что порождает желание его изменить на устраивающее. Подробнее о ней читай в статье «Понятие «проблема» выше в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
[3] Смотри статью выше в разделе 4. «Ключевая разовая проблема, мешающая повышению ПИТ».
[4] Читай также статью «Различия между процессной задачей (ПЗ) и целевой задачей (ЦЗ)» выше в разделе 6. «Система управления потоком задач (Система УПЗ)».
[5] От слова эпизод (греч. epeisódion, вставка) – отдельное небольшое событие, происшествие.
[6] Смотри статью «Воспроизводимая идентификация Запускающих Событий (ЗС)» ниже в настоящем разделе в подразделе 7.1. «Генерирование процессных задач».
[7] Подробнее читай о ней в статье «Методика «Управляемая событиями цепь процессов» (Event-driven Process Chain - EPC)» ниже в разделе 8. «Применяемые в ТУЗ известные методики, методологии и теории».
[8] СПОНТАННЫЙ - ая, -ое [от лат. spontaneus - произвольный]
[9] От слова эпизод (греч. epeisódion, вставка) – отдельное небольшое событие, происшествие.
[10] Подробнее о ЗЭЗ читай в статье «Воспроизводимое генерирование Запоточенных Эпизодических Задач (ЗЭЗ)» ниже в настоящем разделе в подразделе 7.3. «Выполнение запоточенных задач».
[11] Об этом индексе я подробнее расскажу ниже в статье «Раздел «Атрибуты ПС» Типового Реестра Процедур» в настоящем разделе.
[12] Подробнее об этой методике читай статью «Методика «Управляемая событиями цепь процессов» (Event-driven Process Chain - EPC)» ниже в разделе 8. «Применяемые в ТУЗ известные методики, методологии и теории».
[13] При этом надо помнить, что эпизодические задачи – это разновидность процессных задач. Об этом сказано выше в статье «Процессная задача (ПЗ)» в разделе 6. «Система управления потоком задач (Система УПЗ)».
[14] Читай статью «Автоматизированная система управления задачами (АСУЗ)» выше в разделе 6. «Система управления потоком задач (Система УПЗ)».
