Гены в виде РП, полностью или по отдельности, весь РЕЕСТРÓМ в целом или его часть можно копировать и транслировать в другие организации. Можно даже передавать часть гена — отдельный фрагмент процедуры.
Так можно осуществлять обмен опытом, делиться наработками, чтобы избегать «изобретения велосипедов». Делается это в АСУЗ экспортом-импортом.
Можно создать репозитарии генов — Реестров процедур. Эти репозитарии можно сделать открытыми для всех желающих, использующих АСУЗ. Платными или бесплатными.
Так с АСУЗ ТОПы могут экономить время и деньги на разработке универсальных реестров процедур; если кто-то их разработал, ТОПы могут их купить в репозитарии РП либо обменяться с другой организацией.
Это, в свою очередь, позволит:
«клонировать» всю или часть любой организации;
вносить управляемые изменения («мутации»).
Захотел изменить свойства организации, внёс правки в нужные участки генов — Реестров процедур — в триплетный код, то есть подкорректировал «геном» и вот тебе пожалуйста — сразу же работаешь по-новому. Буквально с момента изменения.
Ведь «транскрипция», «транспортировка» и «трансляция» задач и действий от РП в рабочую зону — сотрудникам осуществляются в режиме реального времени, из кода. И если код поменялся, то это сразу же странслируется сотрудникам. Благодаря чему в ту же минуту точно воспроизведутся (реплицируются) необходимые новые свойства. Всё как в живой природе при мутациях.
Таким образом очень просто становится производить управляемые мутации, позволяющие эволюционировать и выживать организации в изменяющихся условиях.
Трудоёмкость и сложность управления изменениями резко снижаются. Теперь это не будет происходить так болезненно и стрессово, как это происходило до изобретения Реестра процедур и РЕЕСТРÓМа.
По сути, с РП, а также с АСУЗ и с системой УПЗ, т. е. с РЕЕСТРÓМом менеджмент превращается — в универсальную операционную систему, которую можно инсталлировать в любую организацию в качестве управляющей системы. Затем её можно сконфигурировать и масштабировать под любые потребности организации.
Всё описанное в АСУЗ работает следующим образом:
В АСУЗ конструируется РЕЕСТРÓМ. Под конкретную организацию. По Технологии Управления Задачами (ТУЗ).
После чего все сотрудники выполняют задачи, сгенерированные РЕЕСТРÓМом в АСУЗ.
ТОП и все сотрудники организации ежедневно запускают АСУЗ с этим РЕЕСТРÓМом.
Входящие запускающие события (ЗС) вносятся в АСУЗ и стартуют работу РЕЕСТРÓМа.
В АСУЗ РЕЕСТРÓМ по цепочке уже внутренних ЗС автоматически генерирует для сотрудников необходимые эпизодические задачи и эпизодические действия. Кибернетически доводит их до сотрудников. Которые те выполняют.
Если входящее ЗС — «Выявлена ситуация, якобы влекущая негативные (неблагоприятные) последствия для организации — потенциальная проблема», то в РЕЕСТРÓМе запускается работа реестров процедур системы Управления Потоком Задач (УПЗ). Из них эпизодические задачи выпадают ТОПу, которые он выполняет. По заданному алгоритму.
Это будут задачи по конструированию РЕЕСТРÓМа — по его правке, дополнению. По сути — это пункт 1. И так эпизодически и регулярно. Цикл за циклом.
Параллельно РЕЕСТРÓМ в АСУЗ агрегирует статистику по всем своим РП. По всему, что в них происходит.
Как в АСУЗ конструируется РЕЕСТРÓМ?
Всё делается, как в конструкторе «Lego»[15]. Из тривиального кирпичика — Реестра процедур.
То есть любая организация, любой конфигурации собирается из наипростейшего элемента — Реестра процедур[16]. Путём позиционирования и связывания (соединения)[17] его с другими себе подобными.
В результате получается новое единство с новыми свойствами и предназначением – новая целостность (эмерджентность[18]) —субсистема, система и в конечном итоге организация[19], как полисистема[20].
Сборка всего этого из Реестров процедур производится по определённой технологии — по Технологии управления задачами (ТУЗ).
По сути, ТУЗ определяет алгоритм такой сборки. Это детальная программа такой сборки.
Из реестров процедур сначала собираем субсистемы, из которых затем - системы, а из систем собираем организацию.
Согласно ТУЗ такая сборка по-крупному осуществляется по следующему алгоритму:
определяем процессную сущность (ПС) и формируем функцию, которую нужно чтобы выполнялась, в отношении её,
берём стандартный кирпичик — Типовой Реестр процедур (ТРП),
копируем его,
конструируем из него конкретный РП для выполнения этой функции,
в ходе конструирования РП:
настраиваем раздел «Атрибуты ПС» и раздел «Процедура»:
наполняем РП шаблонными эпизодическими задачами (ШЭЗ) и шаблонными эпизодическими действиями (ШЭД);
определяем запускающее событие (ЗС);
связываем созданный РП с другими РП
в результате получаем абсолютно уникальный узел — рабочий орган — Реестр процедур, способный выполнить определённую, единственную в своём роде функцию,
переходим к следующему РП,
повторяем пункты 1–7
и так РП за РП.
Приведённый алгоритм – это, по сути, логика преобразования ТРП в РП — алгоритм реплицирования РП из ТРП.
ТРП при этом — это, по существу, шаблон (паттерн, образец, трафарет, «рыба»).
Изначально программа поведения у всех ТРП одна и та же. В рамках этой программы могут выполняться стандартные универсальные действия (манипуляции, в программировании — прецеденты, варианты использования, use case):
Заполнить атрибут сущности в Реестре Процедур — раздел «Атрибуты ПС»,
Заполнить Шаблонное Эпизодическое Действие в Реестре Процедур - раздел «Процедура»,
Поменять очерёдность столбцов в разделе «Атрибуты ПС» Реестра Процедур,
Поменять очерёдность столбцов в разделе «Процедура» Реестра Процедур,
Распечатать реестр процедур или его часть,
Экспортировать (выгрузить) реестр процедур или его часть: в Excel-формат, xml-формат, и другие,
Вставить один или несколько пустых столбцов в раздел «Атрибуты ПС» в РП,
Вставить один или несколько пустых столбцов в раздел «Процедура» в РП,
Удалить один или несколько столбцов в разделе «Атрибуты ПС» в РП,
Удалить один или несколько столбцов в разделе «Процедура» в РП,
Создать на основе РП сводную таблицу,
Выполнить фильтрацию строк по выбранным столбцам и значениям в них,
Привязать столбец из раздела «Атрибуты ПС» к справочнику,
Привязать столбец из раздела «Атрибуты ПС» к другому РП,
Создать в столбце из раздела «Атрибуты ПС» формулы, работающие внутри РП,
Связать столбец из раздела «Атрибуты ПС» в РП формулами с другим РП (одними или несколькими),
Переименовать столбец в разделе «Атрибуты ПС» в РП,
Переименовать столбец в разделе «Процедура» в РП,
Внести в РП новый конкретный процессный объект (КПО),
Внести в РП правки в конкретный процессный объект (КПО),
Изменить разделе «Процедура» в РП состояние ЭД (статус исполнения и фактическую трудоёмкость),
Выдать доступ на просмотр к строкам Реестра процедур
и другие.
Выполнение в том или ином объёме указанных действий, в ходе конструирования (реплицирования) РП из ТРП приводит к тому, что в РП формируется уникальный набор атрибутов ПС, ШЭЗ и ШЭД, которые меняют свойства РП.
РП начинает вести себя по-другому, по-другому реагировать на сигналы. Так, чтобы выполнить функцию.
Его настраивают на стандартное запускающее событие (ЗС). Так чтобы он мог заданным образом отреагировать на наступление своего стандартного ЗС.
Таким образом, путём выполнения перечисленных действий, можно узел в виде РП создать из ТРП под любую функцию.
В рамках сборки субсистемы, системы и организации в целом по описанному выше алгоритму мы создаём узел за узлом — РП за РП. Каждый под свою уникальную функцию. До тех пор, пока полученное в результате единство не начнёт обладать необходимыми и достаточными свойствами для выполнения шаблонной дискретной задачи (ШДЗ).
Сборка осуществляется путём соединения (связывания) РП между собой так, чтобы сначала сформировалась субсистема, выполняющая определённый бизнес-процесс, затем – система, выполняющая миссию, и в завершении — организация в целом, выполняющая несколько миссий. Пример такого связывания можно посмотреть в статье «Логическая структура системы управления потоком задач» в Разделе 6. «Система управления потоком задач (Система УПЗ)». При связывании настраиваются: обмен сведениями между РП, взаимные переходы, отчёты, формулы, гиперссылки и т. д.
При этом в полученном в результате сборки единстве синхронизация узлов — Реестров процедур производится (настраивается) через оценку статистической управляемости и воспроизводимости каждой функции, каждого бизнес-процесса (БП) и миссии в целом. В ходе такой настройки осуществляется балансировка и вносятся правки в нужные РП так, чтобы всё начало выполняться воспроизводимо и, соответственно, синхронно.
Из систем, собранных из РП, конструируется организация, как множество систем – как полисистема. При этом в каждой организации набор РП будет своим.
Кроме набора РП системы УПЗ. Он будет везде один и тот же. Ведь он универсален, независимо от типа организации и её сферы деятельности. Он (набор РП системы УПЗ), по сути, — это операционная система организации[21], которая одинакова и универсальна для всех организаций.
Так следуя Технологии управления задачами (ТУЗ) можно собрать и настроить любую организацию. Организацию любого уровня сложности и разнообразия. Организацию, оперирующую любым количеством процессных сущностей (ПС).
Причём, благодаря универсальности, этот процесс будет управляемым. А не хаотичным и беспорядочным.
Получается, что ТУЗ — это процесс самоорганизации, ведущий к самопроизвольному «рождению сложности».
С её помощью можно масштабировать систему под любые потребности, вызванные обстоятельствами (событиями) внешней среды.
Когда мы хотим изменить свойства системы мы просто по заданному алгоритму вводим в конструкцию РЕЕСТРÓМа новый набор РП, корректируем существующие РП и удаляем утратившие актуальность.
Вводя новые РП, мы без особого напряга берём в оборот всё новые и новые процессные сущности, которые рождаются в ходе турбулентного изменения окружающей среды, возникающего из-за возрастания сложности мира[22].
То есть как бы затягиваем эти процессные сущности во внутрь, как вихрь. Начинаем оперировать ими.
Увеличивая количество РП, мы постепенно наращиваем функциональность организации (ведь мы знаем, что один РП — это одна функция). Отсюда, чем больше РП, тем больше функций. Так мы эволюционно меняем архитектуру организации (в том числе её организационную структуру). Она становится сложнее и разнообразнее.
Благодаря чему сложность и разнообразие организации наращивается прямо пропорционально росту сложности её внешней среды.
Для выполнения описанного выше функционала надо разработать АСУЗ в следующей последовательности:
Сначала разработать компонент «Конструктор РП» модуля «Процессы» АСУЗ
РП — это главный кирпичик РЕЕСТРÓМа. Из него всё собирается.
РП, реплицируемый в АСУЗ из Типового Реестра процедур (ТРП) — это основа архитектуры будущей АСУЗ.
Поэтому надо сначала разработать «Конструктор РП».
Затем необходимо разработать компонент «Конструктор Организаций» модуля «Задачи» АСУЗ.
Ведь РЕЕСТРÓМ создаётся под организацию, для организации.
Этот конструктор позволит формировать архитектуру (набор систем) и организационно-штатную структуру (набор подразделений, должностей, функциональных ролей и сотрудников их выполняющих). Сотрудники будут выполнять задачи и действия, сгенерированные РЕЕСТРÓМом.
Далее разрабатывается такой компонент как «Конструктор РЕЕСТРÓМов» модуля «ПРОЦЕССЫ» АСУЗ.
В нём производится создание РЕЕСТРÓМа организации. Позиционирование, настройка и связывание попадающих в него реестров процедур. Если организаций несколько, то под каждую отдельно.
Низкотрудоёмкое конструирование и ведение «Реестров процедур», совокупно образующих во взаимосвязи друг с другом РЕЕСТРÓМ организации, является главным функционалом АСУЗ.
Также он нужен для экспорта-импорта РЕЕСТРÓМа или его части. Чтобы обмениваться уже разработанными процедурами.
Базовое предназначение РЕЕСТРÓМа — это генерирование в поток задач процессных задач (ПЗ). Дискретных и эпизодических. И в первую очередь эпизодических, так как их в потоке задач 80%. Сгенерированные задачи выгружаются в компонент «Выполнитель потока задач» модуля «Задачи» АСУЗ
Далее делается два компонента параллельно:
Компонент «Выполнитель потока задач» модуля «Задачи» АСУЗ.
Компонент «Декомпозитор проблем» модуля «Стратегия» АСУЗ.
В компонент «Выполнитель потока задач» модуля «Задачи» АСУЗ в автоматическом режиме, в режиме реального времени валятся (выгружаются) все сгенерированные задачи и действия. Закрепляются за выполнителями задач и исполнителями действий.
В нём отслеживается и контролируется выполнение всех задач – потока задач. По сути, осуществляется оперативное управление.
Компонент «Декомпозитор проблем» модуля «Стратегия» АСУЗ — это графическая рисовалка с «летающей логикой». Она нужна для построения различных декомпозиции (ДТР, ДБР, ДП) в виде диаграмм. Это необходимо для наглядной и визуальной, в том числе методом «мозгового штурма» декомпозиции различного вида проблем. С целью выявления причинно-следственных связей между ними.
После разработки компонента «Выполнитель потока задач» модуля «Задачи» АСУЗ необходимо разработать компонент «Анализатор ИСИ» модуля «Стратегия» АСУЗ.
Его главное предназначение выявление и вычленение контента из источников стратегической информации (ИСИ – книг, нормативно-правовых актов, статей, видеороликов и т. д.), который предопределяет требования объективной реальности (ТОР) к организации. То есть те требования, которым организация должна обязательно удовлетворять, чтобы делать то, для чего она создана. Эти требования необходимо учитывать при управлении онтогенезом организации. Для этого их нужно выявлять[23].
После того, как будут разработаны Компонент «Декомпозитор проблем» модуля «Стратегия» АСУЗ и компонент «Анализатор ИСИ» модуля «Стратегия» АСУЗ разрабатывается «Генератор целевых задач» модуля «Стратегия» АСУЗ.
Его предназначение – генерирование целевых задач (ЦЗ), выгрузка их в поток задач – в компонент «Выполнитель потока задач» модуля «Задачи» АСУЗ
Затем разрабатываются последних три компонента параллельно:
Компонент «Конструктор РОС по ПЦР» модуля «Процессы» АСУЗ.
Компонент «Бюджетёр задач» АСУЗ.
Компонент «Мобильное приложение» АСУЗ.
Компонент «Конструктор РОС по ПЦР» модуля «ПРОЦЕССЫ» АСУЗ предназначен для настройки реестров оценки статистики (РОС) о показателях целевых результатов (ПЦР)[24] выполнения дискретных задач, характеризующих работу всего РЕЕСТРÓМа. Для выдачи необходимых для отслеживания и контроля метрик, индикаторов.
Компонент «Бюджетёр задач» АСУЗ нужен для бюджетирования доходов и расходов, поступлений и платежей по задачам. Для их выполнения, в результате их выполнения. Это так называемое бюджетирование «от задач». Ведь деньги нужны для выполнения задач. Деньги приносят выполненные задачи.
Компонент «Мобильное приложение» АСУЗ нужен для оперативного мобильного удалённого доступа к выполнению всех возможных функций АСУЗ. Чтобы использовать время, имеющееся в дали от десктопа, для выполнения этих функций.
В результате АСУЗ будет выполнять роль ДНК, которая несёт в себе генетический код (и весь геном) организации – РЕЕСТРÓМ организации.
Полная версия статьи доступна в моей книге «Задачи чудесные, или Козырная «ТУЗ» Мотаева!»
С уважением к Вам и Вашему делу, Мотаев Александр
Обсудить эту и другие статьи блога вы можете в нашем Telegram-канале Управление потоком задач.
[15] Согласно Википедии Lego — это серии конструктора, представляющие собой наборы деталей для сборки и моделирования разнообразных предметов. Наборы Lego выпускает группа корпораций Lego Group, главный офис которой находится в Дании. Её название выглядит и звучит как лат. и итал. lego — «собираю».
[16] Читай об этом подробнее в статье «Сборка систем и организации из Реестров процедур (онтогенез организации)» в Разделе 7. «Технология управления задачами (ТУЗ)».
[17] В итальянском языке есть производное от Lego слово - legare [leˈɡare] – привязать, привязывать, связывать. Отсюда, слово «легировать» вводить в металл или металлические сплав другой элемент (напр., хром, вольфрам, ванадии, молибден) для получения сталей (легированные стали), обладающих улучшенными физико-химическими или механическими свойствами.
[18] Согласно Википедии эмерджентность или эмергентность (англиц. от emergent «возникающий, неожиданно появляющийся») в теории систем — появление у системы свойств, не присущих её элементам в отдельности; несводимость свойств системы к сумме свойств её компонентов.
[19] Всё как в живом организме. Из такого кирпичика, как ген собираются сначала органы и системы (кровеносная, нервная и др.), а затем весь организм в целом.
[20] О том, что организация – это полисистема, читай в статье «Организация – это…» в Разделе 1. «Введение в управление потоком задач».
[21] Это я обосновывал в статье «Организация – это…» в Разделе 1. «Введение в управление потоком задач».
[22] Читай об этом статью «Размножение сущностей, которыми приходится управлять» в Разделе 3. «Предпосылки появления потребности в повышении производительности интеллектуального труда»
[23] Развёрнуто о работе с Источниками Стратегической Информации (ИСИ) читай в статье «Необходимость управления информацией в информационном обществе» в Разделе 9.
[24] Пример такого Реестра оценки статистики смотри в статье «Реестр Оценки Статистики по ПЦР задачи повышения ПИТ» в Разделе 5. «Задача повышения производительности интеллектуального труда (Задача ППИТ)»
Начать дискуссию