Развертывание операционной системы предприятия — методология транзита
Стратегия цифровой трансформации
I. Резюме для менеджмента
1. Парадигма единой операционной IEM-системы предприятия тотально противоположна философии модульных систем (будь то ERP, либо микросервисная архитектура).
Соответственно, в корне различаются и принципы развертывания: квинтэссенция agile против waterfall.
Для ИТ-профессионалов, знакомых с изнанкой многолетних внедрений узкофункциональных ABC-систем ERP-парадигмы, простота миграции в dia$par будет неожиданной.
Современные технологии, продолжая наращивать внутреннюю сложность, одновременно становится все более простыми и удобными в использовании.
2. Цифровой двойник организации в IEM-системе — информационная структура настолько высокой сложности (complexity), что скорее выращивается в процессе эксплуатации, нежели проектируется в законченном виде.
Муравейник — трансцендентальная сверх-система с позиции отдельного муравья — плавно выращивается в процессе жизнедеятельности муравьиного предприятия, достигая невероятных (относительно единичного сотрудника организации) масштабов и сложности.
А теперь представим шансы на успех проектирования такой суперструктуры «на бумаге» — проектной командой из нескольких (сколь угодно талантливых) муравьев.
Выращивание цифрового двойника (углубление детализации кибернетической модели, расширение состава и интеллектуальности программных роботов IEM) ведется в «боевом режиме» — на уже эксплуатируемой ОС.
Полная IEM-система, состоящая из стандартной IEM-платформы и уникального цифрового двойника, по общей функциональности соответствует операционной системе персонального компьютера с установленными приложениями.
Стандартная IEM-платформа — аналог стандартной (пустой) Windows, а цифровой двойник dia$par — совокупность установленного поверх ОС прикладного софта (от Excel до игр).
Как на ПК сначала ставится «голая» Windows, а вторым шагом, на уже работающую ОС — нужный набор прикладных программ, так и на предприятии. Сначала запускается ОС dia$par в минимальной конфигурации, а потом — уже в рамках работающей операционной системы — функциональность цифрового двойника может наращиваться неограничено.
3. Таким образом, Главной Задачей проекта внедрения является скорейший запуск IEM-системы, производимый в режиме MVP (minimum viable product).
Абсолютно противоположно привычной логике внедрения ERP-систем, фундаментальная ригидность которых фактически закрывает возможность комплексных изменений после передачи системы в эксплуатацию.
Именно поэтому, в общем случае модульной ERP и минимально сложного функционала, — либо он будет детально описан и реализован до запуска системы, либо эксплуатант не получит его никогда.
4. Для запуска прикладными разработчиками интегратора готовится минимальная модель предприятия (ММ).
ММ описывается в Процессном задании на развертывание ОС, которое утверждается Заказчиком в ходе предпроектных коммуникаций.
Чем легче и проще минимальная модель — чем быстрее и комфортнее запуск (параллель с легкими родами некрупного младенца, и наоборот).
5. Композиция минимальной модели Процессного задания ММ описывается тремя группами сущностей:
5.1 скелет цепочек создания стоимости: перечень наиболее важных ЦСС (бизнес-процессов) компании, и их деление на звенья (этапы)
5.2 для каждого звена ЦСС — бизнес-правила пропуска mpacks (см. ниже в «Осмыслении сущностей») на следующее звено
5.3 основные роли (категории) пользователей, и их привязка к звеньям ЦСС
6. Наращивание (полезной) функциональности активного dia$par происходит на порядок быстрее и дешевле, нежели лабораторная разработка идеального цифрового двойника в отрыве от производства (до запуска).
Более того. Какая именно функциональность (и в каком именно виде), будет востребована на самом деле — намного проще понять, когда диаспар уже управляет предприятием.
Рисовать портрет с натуры, — или по словесному описанию толпы очевидцев.
Инженерная аналогия: итеративные улучшения рабочего устройства по результатам практической эксплуатации «в полях» (agile), либо сугубо бумажная разработка идеального девайса в проектном бюро (waterfall).
7. Попытка (в инерционной логике внедрений ERP-систем) детально описать функциональность будущей операционной IEM-системы (то есть, до ее запуска) — фундаментальная методологическая ошибка.
Неизбежное следствие которой — неоправданное затягивание сроков и разрастание бюджетов внедрения.
При этом, как правило, большая часть «богатой функциональности», созданной в рамках лабораторной разработки до запуска ОС, по результатам первых недель эксплуатации уходит на перепроектирование и переделку.
8. Более того, перфекционизм в проработке деталей даже минимальной пред-запускной модели — избыточен.
Архитектурно обусловленная гибкость многоагентной системы прощает ошибки в том числе и в первоначальной формулировке ММ.
Гибкость осьминога, биологической симметрии dia$par, позволяет как угодно изменять даже скелет цепочек создания стоимости — уже в процессе выращивания цифрового двойника на эксплуатируемой системе.
Следование методологии развертывания IEM System гарантирует как быстрый и недорогой запуск, так и комфортную высокоприбыльную эксплуатацию.
II. Фрактал команды проекта: ветвящаяся к низу корневая система two-in-box
1. В ходе разработки Процессного задания минимальная модель предприятия декомпозируется на цепочки создания стоимости (nodes направленного графа), которые, в свою очередь, декомпозируются на звенья.
2. Увидеть актуальную архитектуру проекта вместе с информацией о ходе исполнения как по модели в целом, так и по каждому узлу в отдельности, можно в web-интерфейсе dia$par Change Management Center.
3. Каждый узел в корневой системе проекта всегда имеет двух ответственных (block leaders): со стороны заказчика (.Enterprise — eleader) и со стороны интегратора (.Matrix — mleader).
Иными словами, eleader в деталях знает, как в реальности устроены бизнес-процессы на данном участке. А mleader — как функционирует соответствующий блок ее кибернетической модели.
В простых случаях относительно компактных проектов узел в корневой системе проекта единственный и mleader соответствует классическому проджект-менеджеру интегратора.
За состояние кибернетической модели в целом несут ответственность лидеры транзита (TLs) — со-руководители проекта миграции в dia$par от предприятия (enterprise transit leader — ETL) и команды разработчиков интегратора (model transit leader — MTL) соответственно.
4. Конкретная конфигурация дерева проекта (и ответственных) в общем случае не имеет отношения к бюрократически оформленной организационной структуре компании.
Все block leaders, включая TLs, выбираются исключительно из соображений компетентности.
Каждый блок-лидер несет единоличную полную ответственность со своей стороны за реализацию изменений в рамках собственного функционального блока и на стыках звеньев цепочек создания стоимости с соседями — владельцами смежного функционала.
И зеркально — единолично располагая всеми полномочиями в принятии решений об изменениях в бизнес-логике. В пределах, естественно, собственного блока.
Конкретный сотрудник предприятия может быть лидером произвольного количества блоков, расположенных на произвольных «этажах» дерева декомпозиции модели.
Логическое выделение, и последующее распределение, блоков между кандидатурами лидеров производится исключительно из соображений персональной компетентности.
III. Транзит сетей, холдингов и конгломератов
1. В dia$par может быть помещен бизнес-юнит произвольного размера, если он замкнутый.
То есть если отношения данного бизнес-юнита с прочими компонентами конгломерата могут быть представлены в парадигме «поставщик — покупатель» без потери информации.
Как правило, это или отдельное направление бизнеса (GE Money Bank в составе General Electric), либо обособленный дивизион — как Opel в General Motors.
Выражаясь более формально, отделенный бизнес-юнит может быть эффективно помещен в dia$par, если это компактный узел цепочек создания стоимости, а не произвольно выделенный протяженный фрагмент одной из них (либо нескольких).
2. Переход в dia$par конгломерата в целом является финалом гладкого процесса наращивания периметра dia$par, последовательно поглощающего друг за другом отдельные бизнес-юниты.
Для очень крупных конгломератов со слабо связанными между собой дивизионами (тот же General Electric) работа в едином dia$par не имеет экономического смысла. Много более эффективным решением является помещение каждого независимого направления в собственный диаспар, интеракции между которыми организуются в логике Cyberspace.
Сам же конгломерат, таким образом, кибернетически моделируется локальным сгустком плотности пре-Cyberspace.
3. Обособленный перевод в dia$par функциональных подразделений (как то склад торговой компании, например) формально возможен, но не имеет экономического смысла, вступая в абсолютное противоречие с фундаментальной логикой процессного подхода.
Функциональные подразделения отличаются от логически обособляемых бизнес-юнитов своей незамкнутостью: фактически, это отдельные участки цепочек создания стоимости (отрезок value chain, а не узел).
И начало, и конец которых в общем случае лежат вне пределов компетенции функционального подразделения.
В нашем примере со складом торговой компании «отгрузка товара» (как фрагмент цепочки «продажи») начинается с торгового зала или интернет-магазина.
«Приход товара » как часть цепочки «Закупка», начинается в одноименном департаменте.
IV. Осмысление сущностей. Призма mutual mapping
1. Традиционный для парадигмы ERP подход к автоматизации бизнес-процессов — «модульность» функционала, распределенного согласно бюрократической оргструктуре компании, — должен быть бескомпромиссно отброшен.
2. Для архитектора бизнес-процессов предприятия, управляемого dia$par, наиболее важны два типа сущностей mutual mapping, описывающие ядерную суть бизнеса компании: mchains и mpacks.
О терминологии правильной, и практически используемой
Абстракция mutual mapping использует собственное понятийное пространство с четко определенной терминологией.
Однако поскольку dia$par предназначен для широкого круга бизнес-пользователей, то практически используемая терминология состоит из вполне знакомых слов: «документы», «итоги», «отчеты», etc.
Mchains — это ничто иное, как классические value chains, но в математически стандартизированном понимании mutual mapping.
«Звенья» mchains называются msteps.
Mpacks — это то, что перемещается по виртуальным конвейерам mchains.
«Товар» в максимально широком смысле.
Будучи «сырьем» на первом mstep конкретной mchain, на ее выходе он является «готовой продукцией», передаваемой далее внешним или внутренним (тогда на новую mchain) потребителям.
3. Структура бизнес-процессов произвольной организации может быть описана совокупностью mchains и mpacks.
Абстракция mutual mapping является наиболее естественной из доселе предложенных в КИС — интуитивно-понятной и соответствующей естественной бизнес-логике.
У предпринимателя-менеджера с опытом мышления в процессном подходе освоение mutual mapping потребует усилий не более, чем 15 минут на запоминание нескольких терминов.
Кайдзен с dia$par, или настоящая BPM-система
Как выглядит управление бизнес-процессами на самом деле.
Красивые диаграммы — не самоцель.
4. Две существенно различных бизнес-модели, и пример их осмысления в mutual mapping — для иллюстрации универсальности подхода
Основными mchains торговой компании, состоящей из одного магазина, будут «закупка» и «продажа» (и множество менее значимых).
Перемещаются по этим двум главным mchains mpacks-товары.
В данном случае «товар в широком смысле» соответствует реальным материальным товарам (пиву с шоколадками).
Компания-интегратор dia$par имеет всего один основной mchain: «адаптация кибернетической модели».
«Товарами»-mpacks, перемещающимися по этой mchain, являются параллельно разрабатываемые программистами интегратора фрагменты кода (склад, производство…) кибернетической модели предприятия, готовящегося к переходу в dia$par.
Амбиграмма, изображенная на рисунке ниже, иллюстрирует понятие проекции.
Один и тот же 3D-объект может отбрасывать тени совершенно разной формы — аналогично тому, как проекции полной кибернетической модели предприятия на различно структурированные пространства меньшей размерности (dia$par mfaces) формируют абсолютно разнородные, с бытовой точки зрения, объекты.
При этом если на иллюстрации приведен трехмерный объект, то стартовая размерность пространства цифрового двойника в dia$par — 242, и не имеет ограничений «сверху».
На входе в mchain имеется «сырье» — базовая конфигурация кибернетической модели из дистрибутива.
На конце mchain (соответствующего состоявшемуся переходу в dia$par) — успешно адаптированная до требуемого уровня детализации и полноты соответствия кибернетическая модель, надежно функционирующая в режиме двусторонней репликации mutual mapping.
Путешествуя вдоль главной mchain, фрагменты кода модели переходят по msteps типа «Разработка ТЗ», «Тестирование», etc.
V. Универсальный IEM-тест
1. Возможных вариантов конфигураций модели dia$par.Matrix, которые могут быть практически сопоставлены текущему состоянию конкретного предприятия, больше, чем атомов во Вселенной.
При этом многие на первый взгляд очевидно верные решения (Солнце вращается вокруг Земли), по зрелом размышлении (где его только взять) оказываются явно ошибочными.
2. Естественный вопрос — чем же тогда руководствоваться?
Как сконфигурировать правильную модель?
Как узнать, что именно она правильная?
И как сравнить альтернативные варианты?
Или, хотя бы, — как подойти к решению?
У нас нет ответа типа «42».
Его и быть не может.
3. Однако, поскольку dia$par реализует парадигму IEM System, эксплуатанты должны руководствоваться универсальными, математически обоснованными подходами, разработанными в рамках доктрины IEM Enterprise.
Причем как в отношении поиска оптимальной конфигурации кибернетической модели, так и обнаружения возможностей для прибыльных изменений самого предприятия.
