Совершенно случайно, читая материалы по ISO 15288, я увидел схему «System interaction with Typical Enabling Systems» (оригинальный вид схемы намеренно приведен только в конце статьи), в которой достаточно наглядно изображены:
- виды систем, задействованных в создании и обеспечении работы целевой системы
- связи этих систем с целевой системой.
Мне немедленно захотелось попробовать применить эту схему к разложению на части бизнес-системы, и результатами этой попытки я и делюсь в данной статье.
Одним из основных понятий ISO 15288 является жизненный цикл системы, который схематично изображается следующим образом:
Стадии жизненного цикла отражают следующую идею: «Шаги разработки новой системы можно рассматривать как постепенную «материализацию» системы – постепенный переход от абстрактной потребности к сборке и монтажу пригодных к работе компонентов, совместно выполняющих сложные функции ради удовлетворения данной потребности» [А.Косяков «Системная инженерия», с.143]. Нужно понимать, что это упрощенное изображение реального протекания стадий, которые в реальности могут накладываться во времени друг на друга, чередоваться (например, функционирование системы и ее обслуживание) и т.д. Но нам, тем не менее, этой схемы будет достаточно для визуализации некоторых принципиальных идей.
Я адаптировал идею жизненного цикла применительно к рассматриваемой предметной области бизнес-систем:
Попробуем через призму стадий жизненного цикла посмотреть на устройство бизнес-системы. Сначала изобразим ту целевую систему, которую мы хотим произвести:
В случае бизнес-системы целевая система обычно называется термином «Продукт», его и буду далее использовать как основной. Продукт может быть достаточно сложным (автомобиль), может быть достаточно простым (например, топор), для данной статьи это не важно. Всё есть системы, а все системы имеют жизненный цикл.
Очевидно, что продукт необходимо как минимум произвести, а как максимум – еще прорекламировать, продать, доставить и т.п. На схеме это отображается следующим образом:
Термин «Производственная система» может быть не очень удачен для передачи необходимого смысла, но пока я не придумал ничего удачнее. В бизнесе обычно это называется «Операционная деятельность», но это еще более неудачный термин.
Важные факты, которые отражены в данной схеме:
- Производственная система – это тоже система, которая проходит через свои стадии жизненного цикла.
- Стрелкой показана связь между системами, а именно: Производственная система на стадия «Функционирование» обеспечивает Продукту стадию жизненного цикла «Производство». Или, если говорить проще: на схеме отражен факт, что Производственная система производит Продукт.
- Производственная система частично обеспечивает Продукту стадия «Разработка». Объяснение какой смысл в это вкладывается, будет дан ниже.
Также в бизнес-системе обычно (но не обязательно!) присутствует обслуживающая система, которая занимается «ремонтом» Производственной системы. В термин «ремонты» я включаю и периодическое регламентное обслуживание, и замену негодных частей годными. Обслуживающая система позволяет Производственной системе существовать сколь угодно долго, выполняя свои функции по производству Продукта:
На данном этапе у читателя уже могут появиться вопросы: а откуда берутся Производственная и Обслуживающая системы, а также кто занимается замыслом и разработкой продукта?
Если отвечать на этот вопрос нарративом, то я бы сформулировал это так:
Собирается команда компетентных людей, которые обсуждают концепцию продукта и возможность его произвести.
Если концепцию удовлетворительна и возможность произвести продукт существует, то команда начинает переходить к реализации: разрабатывать подробные проекты Продукта, Производственной и Обеспечивающих систем, а также воплощать проекты Производственной и Обеспечивающих систем в материале.
После воплощения Производственной системы в материале она должна быть готова начать производить Продукт. Отразим данный нарратив в виде схемы:
Важные факты, которые отражены в данной схеме:
1) Во-первых, на этой схеме уже стали видны границы типовой бизнес-системы, которую в данном случае можно назвать системноинженерным термином «система систем» (SoS):
«По сути дела, всякий раз, когда ряд независимых и пригодных к работе систем объединяется для приобретения возможностей, выходящих за пределы суммы возможностей отдельных систем, мы получаем систему систем. Разумеется, уровень комплексирования может существенно различаться. На одном конце спектра находится SoS, полностью интегрированные на самых ранних стадиях разработки, когда отдельные системы, хотя и способные функционировать независимо, проектировались чуть ли не исключительно для SoS. На другом конце мы встречаем системы, слабо связанные для временного решения локальной задачи без каких-либо формальных оснований, кроме согласия своих владельцев», [А.Косяков «Системная инженерия», с.119].
Я думаю, и такие, и такие типы SoS встречаются в бизнес-системах. К этому хотелось бы добавить, что бизнес на верхнем уровне представления- это не «жесткая» иерархическая система, как принято считать, а именно система систем, т.к.:
а) системы в ней находятся в достаточно специфичных связях, а не в связях «Часть-Целое»:
- Система развития замышляет, проектирует и разрабатывает Производственную и Обслуживающую систему;
- Обслуживающая система занимается «ремонтом» Производственной системы.
В данном случае можно также вспомнить теорию деятельности (например, СМД-методологию Г.П. Щедровицкого) и сказать, что системы является объектами и средствами в некоторых деятельностях. При этом их роли могут меняться. Например, в деятельности по созданию Производственной системы, Производственная система является объектом, а Система развития – средством деятельности. Когда Производственная система построена, то она становится средством в деятельности по производству Продукта (или по производству денег в виде прибыли, если смотреть в суть дела)
б) системы достаточно автономны относительно друг друга (могут существовать друг без друга длительные периоды времени), а также могут быть заменены на другие системы (например, обслуживание Производственной системы можно отдать на аутсорсинг).
2) Система развития обеспечивает стадию «Разработка» жизненного цикла Продукта практически полностью, но небольшая часть стадии «Разработка» обеспечивается Производственной системой. На практике так бывает, когда есть потребность уточнять конструкцию продукта на стадии приема заказа клиента. Система развития при этом фактически проектирует целый класс продуктов, а также Производственную систему, которая способна производить этот класс продуктов без своей перестройки. Например, это может быть компания по производству пластиковых окон: Производственная система создается такой, чтобы быть способной производить целую гамму разных по размерам окон, при этом конкретное окно допроектируется при приеме заказа Производственной системой.
В случае же когда Производственная система производит продукт раз за разом без изменений, то Система развития обеспечивает стадию «Разработка» Продукта полностью. Но для других типов компаний (проектные, софтверные) возможны и другие варианты обеспечения жизненного цикла продукта.
Факты, которые не отражены в этой схеме:
- На практике Система развития в цикле развития неоднократно выполняет стадии «Замысел-Проектирование» для Продукта, Производственной и Обслуживающей систем, а также «Производство» для Производственной и Обслуживающей систем.
Как было отмечено в начале статьи, данный тип схем не позволяет лаконично отобразить этот факт. - Кто занимается стадиями «Замысел-Разработка-Производство» для Системы развития?
Очевидно, что сама она появиться из ниоткуда не может. Чаще всего на практике процесс создания «Системы развития» плохо формализован и выглядит следующим образом: основной стейкхолдер (например, инвестор) подыскивает менеджера, который формирует команду. Далее эта команда осуществляет первичные изыскания, о которых уже говорилось выше. Если видится возможность создать бизнес-систему, то команда и становится «Системой развития»: на разовой или постоянной основе. В последнем случае нужно иметь ввиду, что и Систему развития тоже может потребоваться перестроить.
Есть и другие ситуации, когда процесс создания «Системы развития» хорошо формализован, он будет рассмотрен ниже. - Не отражено как происходит списание Производственной и Обслуживающих систем, т.к. на практике это бывает достаточно редко.
Вариант для бизнеса, который занимается услугами/предоставлением сервиса приведен ниже (Рис.7):
В данном случае можно говорить о том, что:
а) Продукта, как отделимого от бизнес-системы артефакта, нет.
б) Производственная система является в данном случае Целевой системой.
в) Производственная система на стадии «Функционирование» оказывает сервис клиентам.
Примером таких бизнес-систем, может послужить парикмахерская или служба такси.
Дополнительно можно рассмотреть расширение приведенной на Рис.6 схемы бизнес-системы для двух случаев.
Первый случай, когда есть необходимость сервисного обслуживания Продукта. В этом случае в должна быть создана еще и Сервисная система для Продукта:
Распространены ситуации, когда Сервисная система принадлежит нескольким владельцам. Например, в случае производства бытовой техники Сервисная система включает себя как предприятие-производитель (производит запчасти), так и сеть сервисных центров, владельцами которых являются отдельные юридические лица.
Очевидно, что при необходимости обеспечить стадию «Списание» Продукта необходимо построить еще и Утилизационную систему. Примером продукта, когда это необходимо, является в настоящее время автомобиль.
Второй случай, который хотелось бы привести, касается работы инвестиционных компаний и венчурных фондов. В данном случае речь уже идет о «машине» по массовому созданию бизнес-систем:
На схеме я отразил тот факт, что Система тиражирования бизнесов частично участвует в замысливании Продукта и Производственной системы. Если замысел оканчивается успешно, то она создает Систему развития, которая продолжает работу по созданию бизнес-системы.
Заключение
В предметной области инжиниринга бизнес-систем один из ключевых вопросов — как выделяются процессы (или функции). Распространен взгляд, что бизнес- это такая кипучая «каша», в которой тесно переплетена сама деятельность с деятельность по улучшению этой деятельности.
Задачей данной статьи было дать четкую картину, что в бизнесе должно быть 3 системы и соответствующие им деятельности. Логика работы (технология) каждой из трех систем – принципиально отличаются. Люди обычно смешивают эти технологии в одно целое и в головах, и в моделях. Ничего хорошего из этого не получается. Поэтому на практике, должно стать понятным, что если, например, главный инженер думает о новой производственной линии, то он в этот момент является бизнес-архитектором, и сидит (выполняет роль) в Системе развития. А если руководит ремонтом производственной линии, то он в этот момент — обслуживающий персонал и сидит в Обслуживающей системе. И время у него должно быть на каждый вид деятельности.
В дальнейшей статье я планирую рассмотреть вопрос моделирования такого структуры бизнес-системы с помощью распространённых нотаций моделирования.
Приложение. Оригинальная схема из ISO 15288
Именно этот вариант изображения схемы взят из документа ISO/IEC TR 24748-1 «TECHNICAL
REPORT. Systems and software engineering — Lifecycle management. Part 1» В практически таком же виде он фигурировал в ISO/IEC 15288:2002, хотя из последней редакции 2015 года эта схема была вынесена в руководство ISO/IEC TR 24748.
Дмитрий Пинаев, ГК «Современные технологии управления»
Комментарии (3)
Dmitry_Pinaev
16.03.2016 10:16Проблем две: хороших моделей нет в открытом доступе. Вторая: менеджеры в своей массе не имеют знаний для "потребления" этих моделей или создания своих.
Но есть и хорошие исключения. Например, В Тандере (Торговая сеть "Магнит"), который сейчас на слуху, сидят 40 аналитиков, которые создают описание бизнес-архитектуры. Результаты налицо.bizobj
16.03.2016 10:48Полностью согласен.
За исключением Магнита. Может на них сильно влияет конъюнктура. Но в целом не могу согласится, что эта сетка (да равно как и другие) обладает разумным экономическим поведением. Чего уж там говорить об аналитиках. Лучше чем нанимать 40 аналитиков по бизнес-архитектуре наняли бы одного профессионального экономиста-управленца. По поводу архитектуры см. Третий фактор: процессуальная сложность.
Вообще складывается такое впечатление, что весь отечественный ритейл занимается отъемом денег у населения под видом продажи низкокачественного продукта с низкокачественным сервисом. Параллельно топ-менеджмент ритейла "играет" в "хороших управленцев" имитирую ответственную деятельность и высокий профессионализм, на деле боясь даже отвечать на острые вопросы потребителей.
Есть вероятность, что топ-менеджмент добросовестно заблуждается или нанимает не тех консультантов.
Надеюсь, что Тандер на правильном пути. Будем ждать результатов. Но вот они пока точно не на лицо (лицом ритейла считаю исключительно его розницу).
bizobj
Интересно и полезно. Спасибо за публикацию. Если позволите, несколько комментариев.
Мне кажется, что основная проблема адекватного представление бизнеса заключается в низком экономическом и управленческом качестве самих моделей организации бизнеса. Отсюда последующая сложная и проблемная автоматизация бизнес-процессов. Менеджмент зачастую вообще не работает квалифицированно в "системе развития бизнеса" и уж тем более ему не под силу "система тиражирования бизнеса". В той или иной степени эффективно решаются конкретные проблемные задачи, но формализация бизнес-модели в самоё её экономической сути — это интерес ограниченного круга лиц. Наверно из-за этого преобладает "процессный" подход в автоматизации управления. А такая важная часть как бизнес-объекты незаслуженно перекладывается с "больной" головы управленцев на "здоровую" голову разработчиков. Топ-менеджмент должен видеть бизнес-модель полностью.
Кстати, ваша методика показалась мне частным случаем применения метода рекурсивно-структурной декомпозиции — поэтому, с вашего позволения, публикация отправляется в избранное.