Управляющий аппарат находится в ядре клетки, и ядерная оболочка защищает его от бурной биохимической деятельности цитоплазмы.
Марков Александр Владимирович[1]
Автоматизированную систему управления задачами (кратко – АСУЗ) я упоминал уже в самом начале блога, в статье «Задача (суть) блога» в разделе 1. «Введение в управление потоком задач». Там я говорил, что АСУЗ должна быть ядром Технологии управления задачами (ТУЗ).
Затем в статье «Инструменты системы управления потоком задач» выше в настоящем разделе я кратко рассказал о функционале будущей АСУЗ.
Думаю, сейчас наиболее подходящий момент для ответа на вопрос: что будет из себя представлять будущая автоматизированная система управления задачами (АСУЗ)?
Разъяснить это надо для того, чтобы читатель понимал, что я прекрасно осознаю допотопность и архаичность тех инструментов, которые были описаны выше. Я чётко знаю, что их применение в организации весьма неудобно и затруднительно. Эти инструменты я описал, чтобы продемонстрировать, что система УПЗ проработана на высоком уровне детализации. Что в рамках малого бизнеса она функционирует и не является какой-то абстракцией, выдумкой, замыслом. Это уже реально работающая архитектура.
В статье «Инструменты системы управления потоком задач» я уже делал оговорку, что это на сегодняшний день не лучшая комбинация применяемых инструментов. Так как сделана она, как говорится, из подручных средств, собрана «на коленках». Но она самая доступная и апробированная. Она уже подстроена под логику системы УПЗ и встроена в Технологию управления задачами (ТУЗ), хотя и громоздкая. Ведь на момент написания блога эта комбинация является единственно возможной для нужд управления потоком задач.
Там же я говорил, что других подходящих инструментов на рынке просто нет. Тем более комплексных. Да и не может быть. Ведь архитектура системы УПЗ и облик ТУЗ мною только-только разработаны и описываются в настоящем блоге.
Никто другой до меня этого не делал. Поэтому на настоящий момент и не может быть никаких готовых решений, отвечающих необходимым системным и функциональным требованиям. Всегда сначала появляется метод, а потом инструмент, созданный на его основе, применяющий его. Об этом я также сказал в статье «Инструменты системы управления потоком задач» и там же привёл объяснения и примеры.
Сейчас же я дам общее описание АСУЗ, но без детального описания её функциональных возможностей, так как они ещё находятся в разработке. Это отдельная не менее сложная задача, которая выполняется на момент написания настоящего блога.
Параллельно с написанием данного блога я пишу техническое задание на разработку уже полноценной и комплексной Автоматизированной Системы Управления Задачами (АСУЗ). Идёт проектирование АСУЗ, описание: прецедентов, классов, интерфейсов, функциональных и нефункциональных требований и т. д.
Как я писал ранее: «даже настоящий блог является частью этого процесса, так как в нем, по сути, описываются начальные системные требования и единый язык, необходимые для определения функциональных требований к АСУЗ».
Итак, приступим. И начнём с предназначения АСУЗ.
Выше в статье «Инструменты системы управления потоком задач» я писал, что необходимостью применения этих инструментов является: «получение продуктивных (т. е. низко трудоёмких) механизмов декомпозиции, фиксации и визуализации (материализации, наблюдаемости) потока задач».
Отсюда, АСУЗ нужна для низкотрудоёмкого управления потоком задач.
То есть её использование должно в разы снизить трудоёмкость всего процесса управления потоком задач.
Для этого АСУЗ должна полностью исключить затраты времени на все ручные механистические повторяющиеся шаблонные эпизодические действия (ШЭД)[2], связанные с генерированием процессных задач (ПЗ)[3], обеспечив экономию трудозатрат в установленных размерах.
Ручные действия – это значит выполняемые вручную человеком, усилиями человека, не автоматически.
Механистические повторяющиеся действия – это значит универсальные, известные, необходимые и обязательные действия, те, над которыми не требуется особо думать; которые, как говорят, надо просто механически и скрупулёзно, физическим усилием исполнить, чтобы продвинуться по процедуре дальше; которые раз от раза, эпизодически, много раз повторяются. Как мой отец любил говаривать: «раз ещё раз, да ещё много-много раз». 
Такие действия, как правило, можно легко автоматизировать и алгоритмизировать. То есть сделать так, чтобы их исполнял не человек, а компьютерная программа или робот.
Почему действия?
Да потому что задачи выполняются путём исполнения действий, действие за действием. Об этом я говорил в статье «Что такое задача?» и в статье «Чем задача отличается от действия?» в разделе 2. «Главная сущность менеджмента – «ЗАДАЧА».
Поэтому автоматизировать надо исполняемые действия. Те, которые механистические. А их много.
В деятельности любой организации в каждый момент времени решается огромное количество интеллектуальных задач. И они постоянно меняются. Я уже говорил, что именно задачи порождают сложность и разнообразие. Именно их количество и изменчивость приводит к усложнению, запутанности и нелинейности.
А так как задачи выполняются исполнением действий, то масса задач, порождает ещё большую массу действий, требующих исполнения. Как правило, одна выполняемая задача, требует в среднем исполнения не менее 5-10-ти действий. И огромное количество из них – это механистические действия. Их множество.
И это множество надо исполнять. Что порождает проблему: «Растрата трудозатрат на выполнение множества ручных механистических повторяющихся шаблонных эпизодических действий (ШЭД), связанных с управлением потоком задач».
Суть этой проблемы заключается в том, что на исполнение этих действий тратятся силы, рабочее время и труд очень дорогостоящих сотрудников – работников интеллектуального труда. А отказаться от исполнения этих действий мы не можем. Так как они обязательные и необходимые. Мы вынуждены их исполнять. И чем больше мы делаем, т. е. чем мы производительнее, тем больше таких действий приходится исполнять. А, соответственно, это растрата ценных трудозатрат.
И делегировать эти действия, например, менее дорогостоящим сотрудникам, не целесообразно, так как затрачиваемое время на делегирование, учёт и контроль их исполнения будет выше времени самого их исполнения. Короче проще и быстрее сделать самому, чем кому-то поручить.
Кроме того, их делегирование приведёт к разрыву единых операций[4], что может породить новую проблему «стыкстроя». То есть, к перепихиванию ответственности, когда будут возникать мелкие нестыковки в примыкающих зонах ответственности – стыках. А как водится «сила мелочей в их количестве».
Остаётся один способ борьбы с указанной выше проблемой – исключить ручное исполнение таких действий путём их автоматизации. Для этого нужно разработать Автоматизированную систему управления задачами (АСУЗ). Её созданием мы преодолеем проблему: «Растрата трудозатрат на выполнение множества ручных механистических повторяющихся шаблонных эпизодических действий (ШЭД), связанных с управлением потоком задач».
Собственно говоря, только для этого она и нужна.
Выше я уже указывал, что без АСУЗ Технология управления задачами (ТУЗ) – невозможна. АСУЗ – это ядро Технологии управления задачам. Без АСУЗ просто не реально выполнять все необходимые транзакции с огромным массивом задач и действий в рамках управления потоком задач.
Так как научно-технологический прогресс создал нам проблему – сложность, посредством цифровизации и развития информационных технологий, спровоцировав «информационный взрыв» и интеллектуализацию труда. Пусть этот прогресс и поможет нам в преодолении проблемы управления сложностью (разнообразием) организации. Как учила меня мама, «клин клином вышибают».
Пусть информационные технологии и цифровизация лягут в основу преодоления этой проблемы. Пусть ядром Технологии Управления Задачами станет Автоматизированная Система Управления Задачами.
Получается, что цифровизация (цифровая трансформация) увеличила сложность управляемых объектов. И она же поможет нам в управлении этой сложностью.
При этом, по моему замыслу, АСУЗ должна полностью поглотить функционал, выполняемый:
1. программным продуктом Flying Logic Pro® (в части функционала, используемого для целей УПЗ),
2. Реестром управления по миссии (в Excel),
3. Реестром оценки статистики по ПЦР миссии (в Excel),
4. АСУЗ «МИРИАДА»® (модулем «Задачи» и модулем «Стратегия»).
То есть АСУЗ должна будет полностью заместить перечисленные и описанные выше инструменты. Она будет вместо них выполнять весь их функционал и ещё многое другое.
Она одна должна будет давать информацию об объекте управления – о потоке задач[5].
АСУЗ будет формировать представление о:
1. логических цепях выполнения задач из потока,
2. количестве активных задач в потоке,
3. структуре потока задач,
4. плотности потока задач,
5. интенсивности потока задач,
6. мощности потока задач,
7. ритмичности потока задач,
8. и т. д.
АСУЗ будет позволять, осуществлять весь цикл управления потоком задач:
1. генерацию, планирование, фиксацию и бюджетирование всех видов задач на всех уровнях управления и т. д. (функция: планирования);
2. декомпозицию, распределение, делегирование и доведение задач до ответственных выполнителей и т. д. (функция: организация);
3. регистрацию результатов, учёт выполнения задач, учёт количества задач и т. д. (функция: учёт)
4. отслеживание сроков выполнения задач, мониторинг и оценку выполнения и т. д. (функция: контроль)
5. координацию, дальнейшую детализацию, отмену, изменение и перераспределение задач и т. д. (функция: регулирование)
6. коммуникацию и получение обратной связи по задачам.
При этом АСУЗ будет позволять выполнять все эти функции:
- в отношении задач любого вида: целевых, процессных, авральных,
- в режиме реального времени - на любой момент времени,
- с минимальной трудоёмкостью.
Таким образом, АСУЗ будет выполнять весь необходимый для управления потоком задач функционал и будет состоять из следующих модулей:
Таблица «Цифровизируемые с помощью будущей АСУЗ задачи и преодолеваемые проблемы»
По моей задумке, АСУЗ должна быть:
- параллельной системой, для которой характерно наличие многих задач, выполняемых одновременно. В системе, с её элементами одновременно и параллельно без проблем должны работать тысячи сотрудников организаций, используя различный её функционал по управлению потоком задач.
- системой реального времени, т. е. параллельной системой с временными ограничениями. Системой обязанной тратить на обработку события время, не превышающее заранее заданное. При этом должно учитываться, что порядок следования внешних событий часто непредсказуем, и периоды обработки таких событий могут перекрываться. В систему в режиме реального времени будет вноситься огромный массив данных тысячами сотрудниками организаций, будут выполняться различные транзакции с задачами и действиями, их количество будет исчисляться сотнями тысяч, и даже миллионами в день. И при этом временные ограничения должны соблюдаться.
- распределённой системой, т. е. параллельной системой, которая исполняется в среде, состоящей из нескольких географически разнесённых узлов. Работающие с системой сотрудники организаций могут быть разбросаны географически (территориально), в том числе находясь «на удалёнке».
В результате, с АСУЗ система УПЗ должна стать ядром, управляющим организацией.
Как я говорил выше в статье «Задача (суть) блога» в разделе 1. «Введение в управление потоком задач»: «создание и обособление системы УПЗ – это и есть обособление ядра организации (как ядра клетки)». При этом АСУЗ будет выполнять в ней роль ДНК, которая несёт в себе генетический код (и весь геном) организации – РЕЕСТРÓМ организации[7] (ударение на последний слог).
В то же время геном организации (РЕЕСТРОМ) будет сформирован в виде совокупности Реестров управления по миссии, состоящих из Реестров процедур. Причём Реестры процедур будут являться хранителями и носителями всей «наследственной информации» о работе организации. А также источником статистических данных для Реестра Оценки Статистики по ПЦР задачи повышения ПИТ, который также будет формироваться и вестись в АСУЗ.
Там эти данные будут обрабатываться с помощью методов статистического анализа, с применением контрольных карт. В результате данные будут превращаться в сведения, «говорящие» нам о том, насколько успешно на каждом дискретном периоде выполняются задачи различных систем организации, их субсистем и Реестров процедур. На основе этих сведений будут делаться выводы об их работоспособности и необходимости совершенствования.
Обобщим.
Новая АСУЗ нужна для низкотрудоёмкого управления потоком задач. Без АСУЗ ТУЗ – невозможна. АСУЗ – это ядро Технологии управления задачами. АСУЗ должна полностью поглотить функционал, выполняемый: (1) программным продуктом Flying Logic Pro® (в части функционала, используемого для целей УПЗ), (2) Реестром управления по миссии (в Excel), (3) Реестром оценки статистики по ПЦР миссии (в Excel), (4) АСУЗ «МИРИАДА»® (модулем «Задачи» и модулем «Стратегия»). Она одна должна будет давать информацию о потоке задач. АСУЗ будет позволять, осуществлять весь цикл управления потоком задач, функции: планирования, организации, учёта, контроля, регулирования, коммуникаций и получения обратной связи по задачам. АСУЗ будет выполнять весь необходимый для управления потоком задач функционал и будет состоять из следующих модулей: Модуль «Процессы»; Модуль «Стратегия»; Модуль «Задачи»; Мобильное приложение АСУЗ; Модуль «Делегирование». При этом АСУЗ должна быть: параллельной системой, системой реального времени, распределённой системой. В результате, с АСУЗ система УПЗ должна стать ядром, управляющим организацией. Где АСУЗ будет выполнять роль ДНК, которая несёт в себе генетический код (и весь геном) организации – РЕЕСТРÓМ организации (ударение на последний слог).
На этом мы завершаем экскурс по инструментам системы управления потоком задач.
Очень надеюсь, что второе издание настоящего блога уже будет содержать описание разработанной АСУЗ.
Далее исследуем вопрос: как мы будем оценивать степень достижения целевого результата бизнес-процессов, выполняемых субсистемами системы УПЗ?
Полная версия статьи доступна в моей книге «ЗАДАЧИ ЧУДЕСНЫЕ, ИЛИ КОЗЫРНАЯ «ТУЗ» МОТАЕВА!»
С уважением к Вам и Вашему делу, Мотаев Александр
Обсудить эту и другие статьи блога вы можете в нашем Telegram-канале "Управление потоком задач".
[1] Стр. 136. «Рождение сложности. Эволюционная биология сегодня: неожиданные открытия и новые вопросы». Марков Александр Владимирович - М.: Издательство АСТ, ООО, 2017. - 528 с., ISBN 978-5-17-084031-1
[2] Подробнее о ШЭД читай в статье «Воспроизводимое моделирование Шаблонных Эпизодических Действий (ШЭД)» ниже в подразделе 7.2. «Технология генерирования процессных задач (Технология ГПЗ)» в разделе 7. «Технология управления задачами (ТУЗ)».
[3] Смотри статью «Процессная задача (ПЗ)» выше в настоящем разделе.
[4] Смотри понятие «операция» в статье «Понятие сущности «ПРОЦЕДУРА» ниже в разделе 7. «Технология управления задачами (ТУЗ)».
[5] О том, что такое «поток задач», читай выше в статье «Поток задач» в разделе 4. «Ключевая разовая проблема, мешающая повышению ПИТ».
[6] ШЭД – это Шаблонное Эпизодическое Действие. Его подробно я описываю в статье «Воспроизводимое моделирование Шаблонных Эпизодических Действий (ШЭД)» ниже в подразделе 7.2. «Технология генерирования процессных задач (Технология ГПЗ)» в разделе 7. «Технология управления задачами (ТУЗ)»..
[7] Читай статью «РЕЕСТРÓМ организации» выше в настоящем разделе.
