Скорость развития рынка телекоммуникаций вынуждает его участников непрерывно совершенствовать свои бизнес-процессы, снижая себестоимость и максимально сокращая время разработки и вывода новых услуг на рынок. Большой проблемой при этом становится построение правильных бизнес-моделей внутри организации. В процессе реализации услуги YouMagic.Pro мы столкнулись с тем, что каждый продуктолог, который начинал заниматься этим проектом, видел его развитие по-своему. Менялись интерфейсы, формы, мы переписывали код, и все это приводило к ошибкам в работе сервиса. В какой-то момент заявленные требования уже перестали быть совместимыми с изначальной архитектурой и мы решили посмотреть, как реализованы бизнес-процессы в других телеком-компаниях. В результате анализа мы пришли к решению внедрить референтные модели SID Frameworx от ТМ Forum. В этой статье мы расскажем, что же такое референтные модели и с чего нужно начинать разработку телеком-сервисов, которые в дальнейшем будут способны адаптироваться под различные изменения бизнес-требований.
Итак, что же такое референтные модели и откуда они взялись.
Для начала рассмотрим понятия бизнес-инжиниринга и инженерного подхода. С помощью технологии бизнес-инжиниринга можно создавать, изменять и реорганизовывать предприятия, а также обеспечивать согласованность различных их компонентов: стратегии, структуры, бизнес-процессы, информационные системы и т. д. Бизнес-инжиниринг, в свою очередь, основан на инженерном подходе, важной особенностью которого является использование формализованных знаний, приспособленных для повторного использования.
Формализованные знания — это знания, которые можно описать, задокументировать и рассказать о них другим людям. Их представляют в графической форме, в виде рисунков, спецификаций, учебников, процедур. Они могут быть словами, номерами и объектами. С точки зрения практики повторно используемые ресурсы и формализованные знания можно разделить на следующие категории:
Во всем разнообразии повторно используемых ресурсов нас заинтересовали референтные модели разработки, внедрения и эксплуатации программного обеспечения для телекома. Они представляют собой эталонные схемы, процедуры и методы организации бизнеса, разработанные на основе реального опыта внедрения в различных компаниях по всему миру. В рамках этой статьи мы остановимся на концепции референтных моделей Frameworx для телекоммуникационных компаний.
Телекоммуникационные и информационные технологии, а также ассортимент предлагаемых компаниями связи услуг развиваются и изменяются чрезвычайно динамично. Сейчас бизнес не может тратить на разработку услуги 1–2 года, как было в связи ранее. В настоящее время срок выхода сервиса на рынок измеряется месяцами. Вместе с ними в постоянном развитии находятся компоненты управляющих информационных систем, а также сами бизнес-процессы. При этом компании довольно часто не располагают временем для проведения полномасштабного проектирования новых процессов. Что уж говорить о разработке, тестировании и внедрении управляющих модулей, которые будут реализовывать в системах новые услуги.
Ещё одной сложностью в управлении бизнес-процессами в телекоммуникационных компаниях является то, что они автоматизируют взаимодействие с клиентами, давая им возможность самостоятельно в реальном времени управлять предоставляемыми услугами. Чаще всего это происходит через веб-интерфейс.
Большинство программистов, или просто технарей, на вопрос про бизнес-процессы в компании ответят: «Это описание того, как заявка от сотрудника поддержки передается в CRM техническому специалисту». Или приведут другой пример из жизни любой компании. Мы посмотрели на это с другой стороны. Подключение клиента и его работа в личном кабинете — это тоже бизнес-процесс. Также существует большое количество скрытых от пользователя бизнес-процессов. Например, разблокировка при пополнении баланса; активация скидок при заказе определенного набора или объема услуг. Все эти бизнес-процессы в подавляющем большинстве случаев автоматизированы в услугах. Когда бизнес-процесс автоматический, то субъекты (люди) практически отсутствуют, и код управляет объектами бизнес-процесса. И поскольку субъекты — это код, то он не может принять человекоподобные решения в условиях недостаточности информации. В таком варианте на первое место выходит построение универсальных и эффективных моделей данных для манипуляции ими автоматическим кодом.
В процессе проектирования ядра продукта «МТТ Бизнес» мы изучили существующий опыт и нашли решение: использовать информационные фреймворки. Они описывают типовые структуры построения моделей, данных для отраслей или предметных областей. Начиная от общего описания основных объектов (для нас, например, это клиент, услуга, тариф и т. д.) и вплоть до конкретных диаграмм компонентов, уже описанных в нотации UML. В них уже заложены best-practices опыта специалистов, которые решали аналогичные проблемы ранее.
Tele Management Forum (TM Forum) — это некоммерческая ассоциация, которая объединяет предприятия электросвязи и их поставщиков с целью написания стандартов, рекомендаций и моделей для информационных технологий в телекоммуникационной отрасли. Ассоциация основана в 1988 году по инициативе компаний British Telecom и AT&T и сначала называлась OSI/Network Management Forum. К началу 1989 года была одобрена первая спецификация протокола OSI/NM Forum, а уже в 1990 году в организацию входило 85 компаний из 13 стран. В дальнейшем TM Forum объединила практически все мировые телекоммуникационные компании.
Основными направлениями исследований и разработок TM Forum стали:
Frameworx — это развитие концепции NGOSS. Как уже было сказано, основная задача этой концепции состоит в определении стандартов для бизнес-процессов операторов связи, а также в унификации форматов представления используемых в системах управления данных и интерфейсов. Особенности концепции Frameworx стали несколько факторов.
1. Разделение бизнес-процессов и применяемых технических компонентов.
Любой бизнес-процесс должен управляться как часть централизованной инфраструктуры. Для этого используются механизмы, которые обеспечивают последовательность выполнения действий. Они также отвечают за осуществление контроля хода бизнес-процесса от одного приложения до другого.
2. Распределенная система с нежесткими связями между ее элементами.
Frameworx подразумевает под собой создание «распределенных систем» с нежесткими связями между их элементами. Это означает, что вместо единого монолитного приложения для управления всеми операциями телекоммуникационной компании предлагается использовать набор интегрированных и взаимодействующих друг с другом приложений.
3. Общая информационная модель.
Приложения, работающие в концепции Frameworx, должны уметь обмениваться друг с другом различного рода данными. При этом каждое приложение должно понимать, как любое другое приложение интерпретирует любой блок переданных данных. Подобная модель работы называется общей информационной моделью.
Основу концепции образуют карты и модели бизнес-процессов. Frameworx включает в себя следующие структуры:
Информационная модель (information framework) является составной частью Frameworx и определяет подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи.
Информационная структура (SID) представляет собой базовую модель и общий словарь всей информации, необходимой для осуществления бизнес-процессов. Использование SID снижает сложность обслуживания, системной интеграции, разработки и проектирования.
С точки зрения практики SID Framework можно представить в виде схемы.
Продукт «МТТ Бизнес» имеет двухуровневую архитектуру:
Портал взаимодействует с BackEnd API по HTTP JSON RPC2.0. С учетом того, что большинство услуг в нем предполагают предоставление услуг связи, то можно сказать, что есть и третий уровень — уровень телекоммуникационной сети.
При принятии такого решения мы также понимали, что помимо одного портала продукта «МТТ Бизнес» к тому же API могут быть подключены другие порталы, реализующие аналогичные услуги и бизнес-правила. Наши ожидания оправдались, и через год после запуска в продакшен продукта «МТТ Бизнес» мы подключили к API двух партнеров с аналогичными услугами без каких-либо существенных доработок.
Для реализации бизнес-логики в API мы реализовали несколько доменов SID Framework: Product, Customer, Service, Resource. Реализация услуги «МТТ Бизнес» на этапе разработки не потребовала реализации всех бизнес-сущностей (ABE) из этих доменов. Это связано с тем, что, например, процесс сопровождения услуги реализован в других системах и такие бизнес-сущности, как Customer Problem, Customer SLA, Service Trouble и т. д., покрываются этими системами. На схеме ниже отражены бизнес-сущности, реализованные в «МТТ Бизнес».
«МТТ Бизнес» имеет приватное API, которое позволяет партнерам МТТ реализовать аналогичные телеком-услуги с его помощью. Если при этом ориентироваться только на интерфейсы API, то можно заметить, что они не в полной мере отражают SID Framework. Он реализован внутри и составляет скрытое от пользователя API ядро. Такой выбор был намеренным — в самом API отражены конечные бизнес-процессы, а не абстракции.
SID также содержит рекомендации по реализации взаимодействия между бизнес-сущностями разных доменов. В нашем случае основное взаимодействие локализовано между продуктами, услугами и ресурсами. Лучше всего это отражает соответствующая диаграмма SID.
Для наглядного представления того, как использованы эти бизнес-сущности и домены в «МТТ Бизнес», на диаграмме ниже отражены маркетинговые наименования услуги «Виртуальная АТС», которая является одной из ключевых в «МТТ Бизнес».
Любой выбор предполагает последующую оценку эффектов, к которым он приводит. Формализовано или нет. Конечно, когда мы выбирали этот подход, мы не были уверены, эффективен ли он будет в дальнейшем развитии кода, систем, услуг и продукта. И предполагали, что потребуется формальный аудит и оценка, пусть, возможно, и внутренняя, для себя. Однако сама собой прошла «проверка жизнью». В процессе многочисленных доработок, внедрений новых услуг, реализации маркетинговых акций и пр. доработки кода во многих случаях были минимальными, что позволило реализовать больше идей бизнеса, чем это было возможно в услугах с проектированием архитектуры без оглядки на референтные информационные модели. Сейчас в планах реализовать этот подход к управлению данными на уровне всего предприятия для реализации стратегической цели по интеграции и созданию любого сервиса на платформе МТТ за 2 недели.
Используемые источники
Референтные модели и технологии бизнес-инжиниринга
Кудрявцев Д.В. Технологии бизнес-инжиниринга: учеб. пособие / Д.В. Кудрявцев, М.Ю. Арзуманян, Л.Ю. Григорьев. — СПб.: Изд-во Политехн. ун-та, 2014. — 427с.
Референтные модели
Итак, что же такое референтные модели и откуда они взялись.
Для начала рассмотрим понятия бизнес-инжиниринга и инженерного подхода. С помощью технологии бизнес-инжиниринга можно создавать, изменять и реорганизовывать предприятия, а также обеспечивать согласованность различных их компонентов: стратегии, структуры, бизнес-процессы, информационные системы и т. д. Бизнес-инжиниринг, в свою очередь, основан на инженерном подходе, важной особенностью которого является использование формализованных знаний, приспособленных для повторного использования.
Формализованные знания — это знания, которые можно описать, задокументировать и рассказать о них другим людям. Их представляют в графической форме, в виде рисунков, спецификаций, учебников, процедур. Они могут быть словами, номерами и объектами. С точки зрения практики повторно используемые ресурсы и формализованные знания можно разделить на следующие категории:
Во всем разнообразии повторно используемых ресурсов нас заинтересовали референтные модели разработки, внедрения и эксплуатации программного обеспечения для телекома. Они представляют собой эталонные схемы, процедуры и методы организации бизнеса, разработанные на основе реального опыта внедрения в различных компаниях по всему миру. В рамках этой статьи мы остановимся на концепции референтных моделей Frameworx для телекоммуникационных компаний.
Преимущества реализации существующих моделей над проектированием с нуля
Телекоммуникационные и информационные технологии, а также ассортимент предлагаемых компаниями связи услуг развиваются и изменяются чрезвычайно динамично. Сейчас бизнес не может тратить на разработку услуги 1–2 года, как было в связи ранее. В настоящее время срок выхода сервиса на рынок измеряется месяцами. Вместе с ними в постоянном развитии находятся компоненты управляющих информационных систем, а также сами бизнес-процессы. При этом компании довольно часто не располагают временем для проведения полномасштабного проектирования новых процессов. Что уж говорить о разработке, тестировании и внедрении управляющих модулей, которые будут реализовывать в системах новые услуги.
Ещё одной сложностью в управлении бизнес-процессами в телекоммуникационных компаниях является то, что они автоматизируют взаимодействие с клиентами, давая им возможность самостоятельно в реальном времени управлять предоставляемыми услугами. Чаще всего это происходит через веб-интерфейс.
Большинство программистов, или просто технарей, на вопрос про бизнес-процессы в компании ответят: «Это описание того, как заявка от сотрудника поддержки передается в CRM техническому специалисту». Или приведут другой пример из жизни любой компании. Мы посмотрели на это с другой стороны. Подключение клиента и его работа в личном кабинете — это тоже бизнес-процесс. Также существует большое количество скрытых от пользователя бизнес-процессов. Например, разблокировка при пополнении баланса; активация скидок при заказе определенного набора или объема услуг. Все эти бизнес-процессы в подавляющем большинстве случаев автоматизированы в услугах. Когда бизнес-процесс автоматический, то субъекты (люди) практически отсутствуют, и код управляет объектами бизнес-процесса. И поскольку субъекты — это код, то он не может принять человекоподобные решения в условиях недостаточности информации. В таком варианте на первое место выходит построение универсальных и эффективных моделей данных для манипуляции ими автоматическим кодом.
В процессе проектирования ядра продукта «МТТ Бизнес» мы изучили существующий опыт и нашли решение: использовать информационные фреймворки. Они описывают типовые структуры построения моделей, данных для отраслей или предметных областей. Начиная от общего описания основных объектов (для нас, например, это клиент, услуга, тариф и т. д.) и вплоть до конкретных диаграмм компонентов, уже описанных в нотации UML. В них уже заложены best-practices опыта специалистов, которые решали аналогичные проблемы ранее.
Почему мы выбрали ТМ Forum и Frameworx
Tele Management Forum (TM Forum) — это некоммерческая ассоциация, которая объединяет предприятия электросвязи и их поставщиков с целью написания стандартов, рекомендаций и моделей для информационных технологий в телекоммуникационной отрасли. Ассоциация основана в 1988 году по инициативе компаний British Telecom и AT&T и сначала называлась OSI/Network Management Forum. К началу 1989 года была одобрена первая спецификация протокола OSI/NM Forum, а уже в 1990 году в организацию входило 85 компаний из 13 стран. В дальнейшем TM Forum объединила практически все мировые телекоммуникационные компании.
Основными направлениями исследований и разработок TM Forum стали:
- Разработка концепции New Generation Operations Systems and Software (NGOSS). Это главная инициатива TM Forum. Она заключается в упрощении и стандартизации процессов определения, разработки и внедрения OSS/BSS-систем в телекоммуникационной индустрии.
- Моделирование и автоматизация процессов.
- Регламентирование взаимодействия с потребителями услуг.
Концепциями TM Forum пользуются во всем мире лидеры рынка информационных и телекоммуникационных услуг.
Frameworx
Frameworx — это развитие концепции NGOSS. Как уже было сказано, основная задача этой концепции состоит в определении стандартов для бизнес-процессов операторов связи, а также в унификации форматов представления используемых в системах управления данных и интерфейсов. Особенности концепции Frameworx стали несколько факторов.
1. Разделение бизнес-процессов и применяемых технических компонентов.
Любой бизнес-процесс должен управляться как часть централизованной инфраструктуры. Для этого используются механизмы, которые обеспечивают последовательность выполнения действий. Они также отвечают за осуществление контроля хода бизнес-процесса от одного приложения до другого.
2. Распределенная система с нежесткими связями между ее элементами.
Frameworx подразумевает под собой создание «распределенных систем» с нежесткими связями между их элементами. Это означает, что вместо единого монолитного приложения для управления всеми операциями телекоммуникационной компании предлагается использовать набор интегрированных и взаимодействующих друг с другом приложений.
3. Общая информационная модель.
Приложения, работающие в концепции Frameworx, должны уметь обмениваться друг с другом различного рода данными. При этом каждое приложение должно понимать, как любое другое приложение интерпретирует любой блок переданных данных. Подобная модель работы называется общей информационной моделью.
Основу концепции образуют карты и модели бизнес-процессов. Frameworx включает в себя следующие структуры:
- Расширенная карта бизнес-процессов eTOM (process framework). Она описывает структуру бизнес-процессов телекоммуникационных компаний. Базовый элемент этого фреймворка — business task (задача). Задача может быть процессным элементом, когда, например, совокупность отдельных задач объединяется в некий flow.
- Информационная модель SID (information framework). Определяет подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи. Базовый элемент фреймворка — logical / business entity (информационный объект).
- Карта приложений TAM (application framework). Описывает типовую структуру компонентов информационной среды предприятий связи. Базовый элемент этого фреймворка — functionality (функциональность). Это некий набор функций, образующий минимально возможную функциональную единицу. Совокупность одной или нескольких функциональностей образует application (приложение).
- Архитектура интеграций и договорные определения интерфейсов (integration framework). Базовый элемент фреймворка — сервис / контракт. Сервис — это совокупность функций и информационных объектов, выставленных системой наружу с целью взаимодействия с окружающей средой. Сервис — это то, что о приложении должны знать другие приложения.
- Референтная модель бизнес-метрик.
- Практические рекомендации и примеры использования.
SID Framework
Информационная модель (information framework) является составной частью Frameworx и определяет подход к описанию и использованию данных, задействованных в бизнес-процессах компании связи.
Информационная структура (SID) представляет собой базовую модель и общий словарь всей информации, необходимой для осуществления бизнес-процессов. Использование SID снижает сложность обслуживания, системной интеграции, разработки и проектирования.
С точки зрения практики SID Framework можно представить в виде схемы.
Как и где мы применили SID
Продукт «МТТ Бизнес» имеет двухуровневую архитектуру:
- Web-портал только с необходимой логикой внутри.
- BackEnd API с реализацией всех бизнес-процессов.
Портал взаимодействует с BackEnd API по HTTP JSON RPC2.0. С учетом того, что большинство услуг в нем предполагают предоставление услуг связи, то можно сказать, что есть и третий уровень — уровень телекоммуникационной сети.
При принятии такого решения мы также понимали, что помимо одного портала продукта «МТТ Бизнес» к тому же API могут быть подключены другие порталы, реализующие аналогичные услуги и бизнес-правила. Наши ожидания оправдались, и через год после запуска в продакшен продукта «МТТ Бизнес» мы подключили к API двух партнеров с аналогичными услугами без каких-либо существенных доработок.
Для реализации бизнес-логики в API мы реализовали несколько доменов SID Framework: Product, Customer, Service, Resource. Реализация услуги «МТТ Бизнес» на этапе разработки не потребовала реализации всех бизнес-сущностей (ABE) из этих доменов. Это связано с тем, что, например, процесс сопровождения услуги реализован в других системах и такие бизнес-сущности, как Customer Problem, Customer SLA, Service Trouble и т. д., покрываются этими системами. На схеме ниже отражены бизнес-сущности, реализованные в «МТТ Бизнес».
«МТТ Бизнес» имеет приватное API, которое позволяет партнерам МТТ реализовать аналогичные телеком-услуги с его помощью. Если при этом ориентироваться только на интерфейсы API, то можно заметить, что они не в полной мере отражают SID Framework. Он реализован внутри и составляет скрытое от пользователя API ядро. Такой выбор был намеренным — в самом API отражены конечные бизнес-процессы, а не абстракции.
SID также содержит рекомендации по реализации взаимодействия между бизнес-сущностями разных доменов. В нашем случае основное взаимодействие локализовано между продуктами, услугами и ресурсами. Лучше всего это отражает соответствующая диаграмма SID.
Для наглядного представления того, как использованы эти бизнес-сущности и домены в «МТТ Бизнес», на диаграмме ниже отражены маркетинговые наименования услуги «Виртуальная АТС», которая является одной из ключевых в «МТТ Бизнес».
Что дальше?
Любой выбор предполагает последующую оценку эффектов, к которым он приводит. Формализовано или нет. Конечно, когда мы выбирали этот подход, мы не были уверены, эффективен ли он будет в дальнейшем развитии кода, систем, услуг и продукта. И предполагали, что потребуется формальный аудит и оценка, пусть, возможно, и внутренняя, для себя. Однако сама собой прошла «проверка жизнью». В процессе многочисленных доработок, внедрений новых услуг, реализации маркетинговых акций и пр. доработки кода во многих случаях были минимальными, что позволило реализовать больше идей бизнеса, чем это было возможно в услугах с проектированием архитектуры без оглядки на референтные информационные модели. Сейчас в планах реализовать этот подход к управлению данными на уровне всего предприятия для реализации стратегической цели по интеграции и созданию любого сервиса на платформе МТТ за 2 недели.
Используемые источники
Референтные модели и технологии бизнес-инжиниринга
Кудрявцев Д.В. Технологии бизнес-инжиниринга: учеб. пособие / Д.В. Кудрявцев, М.Ю. Арзуманян, Л.Ю. Григорьев. — СПб.: Изд-во Политехн. ун-та, 2014. — 427с.