Продолжение публикации. С первой частью материала вы можете ознакомиться по ссылке: Построение верхнероувневой модели деятельности компании на основе принципов системной инженерии. Глава 1. Процессы или функции?
Принцип «модульности» при проектировании архитектуры
Вернемся к нашей компании. Из предыдущей главы мы теперь знаем, что в нашей модели деятельности верхнего уровня представлены функции. Давайте решим задачу обратную к описываемой выше задаче объединения конкретных процессов: давайте рассмотрим задачу декомпозиции функций. Давайте выясним, есть ли какие-нибудь общие рекомендации, как необходимо декомпозировать функции?
Искать принципы деления я отправился к системным инженерам (есть такая дисциплина — Системная инженерия). Кому как не им — создателям сложных технических систем — знать, как делить систему на части.
Удивительно, но я нашел только один принцип. Это принцип «модульности» или принцип «Сильная сцепленность — слабая связанность» из программирования (tight binding — loose coupling).
Это позволяет уменьшить количество интерфейсов между модулями. Что в свою очередь дает следующие преимущества:
- Возможность легкого изменения конструкции модуля без необходимости серьезно перепроектировать другие модули.
- Возможность легкой замены в проекте одного модуля на другой.
- Более легкая сборка системы из модулей. Эта выгода актуальна и для организационных систем. Например, отлаживать работу двух подразделений сложнее, если между ними много взаимодействий.
- Возможность легкой физической замены неисправного модуля в работающей системе.
- Простота модели. На самом деле это самое главное преимущество, если вспомнить, что основное предназначение модели — объяснить заинтересованным лицам принципы работы системы при ее создании или развитии.
Если говорить про модели деятельности, я думаю, что все видели такие IDEF0 модели, в которых принцип модульности не выполняется. Смотреть на них страшно, ибо связи между функциями напоминают паутину (очень похоже на левую часть рисунка из книги по системной инженерии, не правда ли?).
Любопытно, но классики тоже писали про модульность:
Принцип модульности также может и должен использоваться и при структуризации модели процессов. И нужно отметить, что, в данном случае часто аналитики интуитивно уже его используют. Особенностью моделей процессов является наличие связей предшествования наравне со связями типа «вход-выход» между операциями. Связи предшествования в определенной степени можно считать аналогом интерфейсов между модулями. Принцип модульности при проектировании процессов выражается в том, что процессы на нижних уровнях модели могут иметь достаточно сложные диаграммы: с циклами и ветвлениями. А на верхних уровнях целесообразно выстраивать процессы линейно. Это позволяет получить все описанные выше преимущества модульности.
Принцип «автономности» при проектировании архитектуры организационной системы
Итак, у нас есть первый принцип - принцип «модульности». К сожалению, если мы будем пользоваться только им для создания модели организационной системы, наши модели будут красивые, но… не очень понятные. Это происходит по следующей причине.
Организация — это саморазвивающаяся система. С этим тезисом сложно не согласиться: концепция постоянных улучшений зафиксирована во многих школах менеджмента: в стандарте ISO 9001 (Система менеджмента качества), в бережливом производстве (Lean) и в BPM. Процессы изменений идут постоянно, а это значит, что компания физически перестраивается. При этом деятельность по производству продукта -то, ради чего компания создавалась — не должна останавливаться.
Наверное поэтому, в существующих подходах эти два принципиально разных вида деятельности принято… смешивать. Нередко можно увидеть рекомендуемый фреймворк, в котором к «процессу по производству чего-либо» (понятие «производство» в данном контексте используется в широком смысле) приложен процесс по улучшению этого процесса.
Схема сознательно содержит ряд распространенных логических ошибок.
Но, если мы для каждого процесса будем идти таким путем, то как это скажется на объеме и понятности модели? А насколько с точки зрения здравого смысла корректно смешивать и показывать в одной модели, как мы едем на автомобиле и одновременно ремонтируем его? Или как работает кофеварка и как она себя улучшает? В технических системах это кажется абсурдным. Но в моделях организации это является распространенным подходом.
Разобраться с этой проблемой нам снова поможет системная инженерия. В ней существует такое важное понятие, как жизненный цикл (ЖЦ) системы. Один из простых вариантов жизненного цикла выглядит так (ISO 15288:2002 Life Cycle Management — System Life Cycle Processes, редакция именно 2002 года):
Жизненный цикл системы отражает простую идею. Система проходит через разные стадии воплощения: концепция, проект, материальное воплощение; затем она функционирует и обслуживается; и в конце утилизируется. Согласно идеям системной инженерии каждую стадию ЖЦ системы должны обеспечивать другие системы — обеспечивающие (Enabling Systems). Это отражено на следующей, более сложной схеме:
Взаимодействие системы с типовыми обеспечивающими системами
Из этой схемы мы можем почерпнуть следующие мысли:
- И наш продукт (Целевая система, System of Interest), и то, что его создает — всё есть системы.
- Для каждой стадии ЖЦ целевой системы, кроме стадии «функционирование», должна быть внешняя система, которая обеспечивает прохождение этой стадии. Внешняя система в этот момент находится на своей стадии «Функционирование» (Utilization). В данном примере таких систем 5, но их может быть больше или меньше (если внешняя система обеспечивает несколько стадий).
- Система сама развиваться не может. Для этого ей нужны другие системы.
Попробуем применить данный подход к компании. Начнем с первой системы.
Это наш продукт, который мы передаём внешнему клиенту. Чтобы произвести продукт (обеспечить их стадию «производство»), нам нужен «завод» (будем называть его на схеме Операционной системой), который может принять заказы, произвести продукты и отгрузить их клиентам, заниматься обслуживанием продуктов и утилизацией (сейчас актуально думать о всем ЖЦ продукта, будем думать и мы в обобщенной схеме). Ограничим возможности завода: он может только работать по предписанной технологии, производя заданную линейку продуктов и ничего больше. Сам себя он развивать не может. Впрочем, как и продукты, сами себя они развивать не могут.
В обобщенной схеме левая граница зоны ответственности Операционной системы включает в себя часть стадии ЖЦ Продукта «Разработка». В зависимости от отрасли и серийности производства эта граница может смещаться как на стадию «Замысел», так и не затрагивать стадию «Разработка» совсем.
Пример 1: В ИТ-компании стадия «Разработка» и, почти целиком, стадия «Замысел» входят в зону ответственности Операционной системы, т. к. сайт — это во многом эксклюзивный продукт (граница смещается влево). И для операционной системы производство сайта является «обычным делом», ради которого она спроектирована и создана.
Пример 2: На автомобильном заводе модель автомобиля проектируется заранее целиком. Даже если мы говорим про возможность выбора опций автомобиля клиентом, сам перечень опций — фиксирован. Поэтому фиксировано и возможное множество конструкций автомобиля. Поэтому Операционная система не участвует в стадии «Разработка» продукта (граница смещается вправо).
Мы получили первую минимально работоспособную схему. Построенный «завод» может без изменений производить заданный перечень продуктов на протяжении заданного срока (месяц, год, 10 лет — неважно). Мы можем для этого минимально необходимого функционала создать свою простую модель. Этим мы займемся чуть позже.
Расширим задачу. На практике нашему «заводу» может потребоваться техническое обслуживание: профилактика и замена сломавшихся частей. Это стадия ЖЦ «Обслуживание», но уже для завода. Кто будет этим заниматься? Ну конечно же… система! Отразим Обслуживающую систему, которая будет заниматься обслуживанием завода:
Замечательно! Теперь наш завод может работать, вечно производя заданный перечень продуктов!
А откуда берутся Производственная и Обслуживающая системы? Наверное, их делает… еще одна система! Отразим этот факт на схеме:
Система развития замышляет, проектирует и производит Операционную систему под определённую продуктовую линейку. Ведь невозможно создать завод, который может производить всё что угодно. Поэтому представление о продукте должно появляться раньше начала проектирования Операционной системы.
Также Система развития замышляет, проектирует и производит Обслуживающую систему под определенную Операционную систему. А также может обеспечивать стадию «Замысел» и «Разработка» продукта.
Пример 1: В ИТ-компании, занимающейся разработкой сайтов, небольшая начальная часть стадии «Замысел» Продукта входит в зону ответственности Системы развития, т. к. в силу эксклюзивности продукта мы можем изначально задать только продуктовую линейку (классы продуктов), которую мы планируем выпускать. Зная продуктовую линейку, мы можем сделать проект Операционной системы, в которой опишем, как мы будем создавать сайты, а также можем выдвинуть требования к квалификации персонала. Далее Продуктом будет заниматься уже Операционная система и ее персонал.
Пример 2: На автомобильном заводе Система развития обеспечивает стадии «Замысел» и «Разработка» продукта. Зная продукт, мы можем создать Операционную систему один раз на весь срок производства модели автомобиля.
На этой схеме уже стали видны границы Бизнес-системы, которую в данном случае можно назвать системноинженерным термином «система систем» (System of Systems).
Перерисуем наши умозаключения в таком компактном фреймворке, отразив на нем только системы и их границы:
На входе у Обслуживающей системы находятся ресурсы, необходимые для обслуживания, и части операционной системы. Этими частями может быть:
- оборудование (которое мы обслуживаем, ремонтируем или заменяем);
- здания и сооружения (которые мы ремонтируем);
- элементы ИТ-инфраструктуры;
- персонал (который мы переподготавливаем или заменяем в силу разных причин);
- и ресурсы, необходимые для проведения восстановительных работ, в том числе и новый персонал.
На выходе — части операционной системы, «инсталлированные» обратно в «завод».
Важно подчеркнуть, что Обслуживающая система не может менять архитектуру Операционной системы. Она может только ее «чинить».
Добавим, что на практике Обслуживающая система также занимается и обслуживанием самой Системы развития.
Система развития — это та система, которая создает и улучшает Операционную и Обслуживающие системы. А также полностью или частично придумывает и разрабатывает Продукты компании.
На входе у нее — Ресурсы для создания указанных систем и сами системы или их части. Это означает, что система развития «забирает» из систем их компоненты, модифицирует и возвращает назад. Этими частями могут быть как оборудование, так и персонал, который необходимо переподготовить.
Важным отличием данного фреймворка от других является то, что Система развития проектирует и персонал, и оборудование и ИТ-системы как одно целое. Это позволяет собрать эти элементы, протестировать и получить работоспособную систему (операционную или обслуживающую). Этот подход понятен для технических систем, но в моделях организации создание данных элементов почему-то рассматривают по отдельности, хотя работают-то они вместе! Это все равно, что автомобиль передать клиенту не целиком, а по отдельности: электропроводку, двигатель, топливную систему и кузов.
Полученный фреймворк поразительно напоминает 3 модели IDEF0 уровня А0, расположенные рядом. Пусть он будет для нас руководством к действию для создания Фреймворка деятельности компании в следующей главе.
Резюме
Принцип автономности заключается в том, что мы делим бизнес-систему на подсистемы, которые способны существовать друг без друга. Отношение между этими системами — не горизонтальные по входам и выходам, как в технологической цепочке, а вертикальные:
- Отношение «Создание» — система физически создает другую систему;
- Отношение «Обслуживание» — система ремонтирует другую систему.
Не соглашусь с К.Марксом и выдвину тезис «Сознание определяет бытие». Сущности, которые мы видим в своей голове, влияют на реальность. Признав существование деятельности по развитию компании и определив ее границы, мы можем сделать следующий шаг — сделать вывод, что за нее должен кто-то отвечать.
Я рекомендую вменить ответственность за развитие руководителям всех уровней. Они должны тратить на эту деятельности часть своего рабочего времени. Причем на развитие — в первую очередь, а во вторую — уже на непосредственное участие в операционных процессах, если на это останется время.
По сути, руководитель играет две роли в двух системах:
- Операционной системе — роль «рабочего, который работу работает».
- Системе развития — роль «прогрессора, который думает о том, как работу работать лучше».
Другие принципы декомпозиции
Но перед тем, как перейти к моделированию, давайте рассмотрим еще несколько общих принципов, которые могут нам далее оказаться полезными.
Жизненный цикл — декомпозиция по стадиям ЖЦ ключевого объекта рассматриваемой деятельности. Например: потребитель должен пройти через стадии:
- потенциальный;
- информированный;
- привлеченный;
- обслуживаемый;
- удовлетворенный.
Технологическая цепочка — декомпозиция деятельности по технологическим этапам на основе логических и физических принципов («не сделав, А, нельзя сделать Б»). Этапы связаны горизонтальными входами-выходами: следующему этапу нужны объекты, полученные на предыдущем этапе.
В качестве вспомогательного метода можно применять подход цепочки создания ценности. Но он не может использоваться как основной принцип, т. к. декомпозиция происходит с точки зрения потребителя, а не архитектора системы.
Важное внимание в модели деятельности архитектору необходимо уделять принципам запуска и синхронизации процессов.
Без синхронизации — процесс запускается, если у него на входе появился результат или пришел сигнал (в любой форме) на старт работы из предыдущего процесса.
Синхронизация без планирования — вытягивающая система на основе карточек «канбан». Известен в двух формах:
- Процесс запускается, если его результат нужен в следующем процессе.
- Процесс запускается (объект работы затягивается в систему из очереди), если в системе освободился ресурс. Эта вариация используется в софтовой разработке.
Синхронизация с планированием — предварительный расчет планов на заданный горизонт планирования на основе информации о длительности работ. Используется, когда необходимо синхронизировать множество работ между собой и получить минимальное общее время и/или затраты. В качестве примера можно привести масштабное планирование производственной деятельности по методу MRP2. Функция планирования при этом явно помещается в модель.
Любой из данных способов обеспечивает естественный поток работ без использования традиционной процедуры планирования традиционным руководителем. Вам необходимо выбрать только оптимальный принцип для того или иного вида деятельности.
Июль 2021 г.
Поделиться: