Компании, внедряющие ESM-подход — то есть расширяющие практики сервисного подхода в ИТ ITSM на HR, Legal, АХО и другие подразделения, — сталкиваются с ограничениями традиционных архитектур, которые тормозят цифровую трансформацию и увеличивают нагрузку на ИТ-департамент. Динамическая модель данных открывает новые возможности для построения гибких корпоративных сервисных систем. В статье эксперты SimpleOne рассказывают, как современный подход к организации данных позволяет сократить время внедрения изменений и дать бизнес-подразделениям больше автономности.
Почему ESM-трансформация буксует?
Преобразование ИТ-подразделения в сервисную организацию (ITSM) уже доказало свою пользу — понятные процессы, каталоги услуг и предсказуемость результатов позволяют выстроить работу с максимальной отдачей. Однако масштабирование таких сервисных инструментов, как сервисный портал, каталог услуг и автоматизация сквозных процессов на все обслуживающие подразделения компании (это подход ESM — Enterprise Service Management) часто буксует из-за фундаментальных ограничений используемых систем.
Проблемы с гибкостью ESM-систем проявляются на нескольких уровнях, например, при работе с системой департаменты вынуждены заполнять поля, не относящиеся к их бизнес-процессам. При этом чтобы настроить формы запросов под требования каждого отдела нужны дорогостоящие ресурсы, и поэтому компании сталкиваются с зависимостью от ИТ — в большинстве организаций невозможно изменить простую форму запроса услуги без привлечения программистов. В результате адаптация сервисов под потребности бизнеса идёт медленно, а ИТ-отдел перегружен запросами на кастомизацию.
Корень проблемы кроется в архитектуре данных. Традиционные подходы к хранению информации, унаследованные из эпохи статичных бизнес-процессов, не соответствуют современным требованиям к гибкости и скорости адаптации сервисов — изменение формы запроса могло бы быть простой операцией для бизнес-пользователя, не требующий ресурсов ИТ-департамента.
Выход из ситуации предлагает концепция динамической модели данных — это подход, при котором структура данных может меняться или расширяться без изменения основной схемы базы данных. Реализуют подход с помощью технологии REM (Record Extended Model) — этот архитектурный подход к организации данных позволяет настраивать типы заявок с нужными атрибутами, не затрагивая основную систему. Когда HR-отдел может самостоятельно добавить новый вид заявки на подбор персонала, юридический отдел — форму согласования договора, а финансисты — запрос на согласование платежа, скорость внедрения изменений возрастает многократно. При этом не страдает целостность данных и не требуется перестройка всей структуры системы.
«Традиционный подход к построению информационных систем — это как проектирование здания с фиксированной планировкой. Если завтра вам понадобится новая комната, придётся ломать стены. REM-технология превращает вашу ESM-систему в трансформер, который может адаптироваться к новым потребностям без капитального ремонта. Это фундаментально меняет скорость, с которой бизнес может внедрять изменения», — Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG.
Какой подход к организации данных позволит успешно масштабировать сервисный подход на все подразделения компании? Далее разбираемся, как устроены современные системы, и почему архитектура данных становится важным фактором при выборе ESM-платформы.
Подходы к структурированию данных в ESM-системах
Выстраивая ESM-систему, компания выбирает между тремя основными подходами к организации данных. Каждый из них имеет свои особенности, которые напрямую влияют на гибкость системы и скорость внедрения изменений.
1. Широкие таблицы
При этом подходе все типы запросов хранятся в одной таблице со множеством полей. По мере появления новых типов запросов в таблицу добавляются новые поля. Из плюсов широких таблиц: подход достаточно прост в первоначальной реализации, позволяет хранить все данные в одном месте, нет необходимости в сложных JOIN-запросах.
У такого способа хранения данных есть ограничения:
- падение производительности при увеличении количества полей;
- информационный шум — пользователи системы видят много ненужных полей;
- высокая вероятность ошибок при настройке фильтров и представлений;
- технические ограничения СУБД (например, в PostgreSQL — это не более 1600 колонок на таблицу);
- усложнение администрирования по мере роста системы.
2. Наследование таблиц
В этом случае создается базовая таблица с общими полями и множество дочерних таблиц для разных типов запросов. Каждая дочерняя таблица наследует поля родительской и дополняет их своими. Этот подход более структурированный, чем широкие таблицы — у каждого типа запроса есть только нужные поля, данные логически разделены.
Среди ограничений:
- чтобы изменить структуру данных, пользователю нужны административные привилегии в системе, а в некоторых случаях и доступ к базе данных;
- сложно настраивать бизнес-логику, которая распространяется на разные таблицы;
- нужно много времени, чтобы внести изменения в несколько связанных таблиц;
- по мере роста количества таблиц система становится менее гибкой.
Разберем ограничения подхода на примере: для запроса на оборудование создана отдельная таблица с полями «Тип оборудования», «Модель» и «Инвентарный номер». Для запроса на получение доступа — другая таблица с полями «Система», «Уровень доступа» и «Обоснование». Если во все типы запросов нужно добавить поле «Срок исполнения», придется модифицировать каждую таблицу отдельно.
3. Динамическая модель данных и технология REM
В подходе REM используют базовую таблицу со стандартными полями, к которой динамически подключаются дополнительные атрибуты через модели и коллекции атрибутов. При добавлении новых типов запросов не требует изменения структуры базы данных, департаменты могут самостоятельно настраивать свои формы без участия ИТ, и, следовательно, растет time-to-value при внедрении изменений. Благодаря явному разделению атрибутов по моделям, снижается риск ошибок, при этом в системе нет информационного шума — пользователи видят только релевантные поля.
Пример: отдел бухгалтерии самостоятельно создает модель «Согласование платежа» с коллекцией атрибутов «Платежные реквизиты». HR-отдел использует модель «Подбор персонала» с атрибутами «Позиция», «Требуемый опыт» и «Предполагаемая зарплата». Для обоих запросов можно использовать общую коллекцию «Сроки исполнения» без дублирования настроек.
Для создания динамической модели достаточно понимать базовые принципы REM. При построении модели нужно внимательно проектировать коллекции и атрибуты, чтобы избежать избыточности данных, дублирования информации и потенциальных конфликтов между моделями с пересекающимися атрибутами.
Что такое REM и как он позволяет строить гибкие ESM-системы?
Расширенная модель записи (Record Extended Model, REM) — это архитектурный подход к организации данных, который позволяет динамически расширять основную структуру без её изменения. В основу REM заложен классический подход EAV.
REM решает фундаментальную проблему корпоративных информационных систем — необходимость гибко адаптироваться к разнообразным потребностям разных департаментов без усложнения структуры данных.
Основные компоненты REM-архитектуры
REM состоит из трех основных компонентов, которые в совокупности обеспечивают гибкость и масштабируемость системы:
- Модель — определяет набор дополнительных полей, которые будут связаны с записями в основной таблице. Для ESM-системы моделью может быть, например, «Запрос на выдачу оборудования» или «Заказ расходных материалов».
- Атрибуты — отдельные поля, хранящие специфическую информацию. Для запроса на выдачу оборудования это могут быть «Тип устройства», «Модель оборудования» и «Количество».
- Коллекции атрибутов — логически сгруппированные наборы полей, которые можно использовать в разных моделях. Например, коллекция «Доставка» может содержать атрибуты «Адрес доставки», «Предпочтительная дата доставки».
Как REM трансформирует ESM-процессы
При традиционном подходе организации данных каждый департамент получает фиксированный набор форм, которые затратно модифицировать. REM меняет эту парадигму и позволяет децентрализовать настройку услуг в ESM-системах — перевести её из зоны компетенций ИТ-департамента в отдельные подразделения и за счёт этого сократить цикл разработки и внедрения изменений.
Кроме того, REM позволяет хранить все запросы в единой таблице, и при необходимости, модель запроса (набор атрибутов) может быть изменен после регистрации заявки с сохранением номера заявки. Это упрощает жизнь конечного пользователя, которому не нужно создавать новые заявки в случае ошибки в выборе модели.
Важным преимуществом REM является тонкая настройка контроля доступа. Благодаря явному разделению информации по моделям, система позволяет гибко управлять правами на уровне отдельных атрибутов и коллекций. Например, HR-департамент может получить доступ только к своим моделям, финансисты — к своим, при этом общие атрибуты могут быть доступны для всех с разными правами на просмотр и редактирование. Такой подход снижает риски утечки конфиденциальной информации и соответствует принципу минимальных привилегий.
REM особенно полезен при создании сложных услуг, требующих взаимодействия нескольких отделов. Например, процесс оформления нового сотрудника включает шаги от HR, ИТ, АХО и бухгалтерии. REM позволяет каждому отделу настроить свою часть процесса, сохраняя целостность данных по всей цепочке.
ESM-платформы с REM-технологией имеют преимущество над другими системами за счёт более высокой производительности, меньшей потребности в ресурсах разработки и упрощенной масштабируемости. REM превращает ESM-платформу из жесткой системы с предопределенными процессами в гибкий конструктор корпоративных сервисов, что особенно ценно в условиях цифровой трансформации.
Сравнение подходов по количеству шагов
Выбор подхода к структурированию данных — это стратегическое решение, которое определит, насколько успешным будет масштабирование сервисного подхода за пределы ИТ-отдела. Чтобы увидеть разницу в трех подходах к структурированию данных, сравним процессы добавления нового типа запроса в ESM-систему:
Шаг | Широкая таблица | Наследование таблиц | REM |
---|---|---|---|
1 | Получение административных прав на изменение структуры БД | Получение административных прав на создание новой таблицы | Создание новой модели (доступно бизнес-пользователю) |
2 | Добавление новых полей в основную таблицу | Создание новой дочерней таблицы с наследованием | Добавление атрибутов или подключение существующих коллекций |
3 | Настройка представлений для скрытия ненужных полей | Настройка представлений для новой таблицы | Настройка формы запроса (встроенная функциональность) |
4 | Создание бизнес-правил с учетом всех существующих полей | Создание бизнес-правил для новой таблицы и/или переопределение существующих | Настройка бизнес-правил в контексте конкретной модели |
5 | Тестирование влияния изменений на всю систему | Тестирование новой таблицы и интеграций | Активация модели |
REM-процесс может выполняться бизнес-пользователями без глубоких технических знаний, что ускоряет цикл внедрения изменений и снижает затраты на специалистов.
«В нашей практике мы видим, что компании, использующие REM-подход, сокращают время внедрения изменений в ESM-процессы в
3-4 раза. Но главное преимущество даже не в этом, а в том, что бизнес-пользователи могут самостоятельно настраивать значительную часть услуг — это меняет всю динамику развития сервисной культуры в организации», — Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG.
Бизнес-кейсы: REM для бизнес-подразделений
Когда организация масштабирует сервисный подход за пределы ИТ-отдела, она сталкивается с разнообразием процессов в различных подразделениях. Каждый департамент имеет свою специфику, уникальные типы данных и требования к их обработке. Традиционные подходы к структурированию информации приводят к созданию жёстких, изолированных систем, которые сложно интегрировать и адаптировать. Рассмотрим на примерах конкретных подразделений, как REM-технология трансформирует рабочие процессы и повышает эффективность взаимодействия.
HR-автоматизация
Отдел кадров работает с разнородными процессами, каждый из которых требует уникального набора полей:
-
Заявления на отсутствие требуют указания дат, типа отсутствия (отпуск, командировка, больничный) и замещающих сотрудников.
-
Запросы на выдачу документов содержат перечень необходимых документов, цель их получения и формат выдачи.
-
Оформление новых сотрудников включает поля для данных о позиции, зарплате, требуемом оборудовании.
Если представить эти поля в одной таблице, система станет громоздкой и неудобной в администрировании. REM позволяет HR-отделу хранить все запросы в единой таблице, при этом каждый тип запроса будет получать только нужные ему атрибуты, также быстро создавать новые виды заявок без изменения структуры таблицы и настраивать формы для разных ролей — руководитель видит один набор полей, сотрудник — другой, HR-специалист — третий.
Автоматизация юридического отдела
Юридический отдел работает с множеством типов документов, требующих разных атрибутов и маршрутов согласования:
-
Договоры с контрагентами требуют информации о контрагенте, суммах, сроках и особых условиях
-
Правовые заключения содержат иной набор атрибутов, включая правовые риски и рекомендации
-
Доверенности содержат информацию о сроках, полномочиях и представителях
Применение REM в юридическом департаменте позволяет создавать гибкие маршруты согласования документов в зависимости от их типа, использовать общие коллекции атрибутов (например, «Контрагент») для разных типов документов.
REM даёт возможность быстро адаптироваться при изменениях законодательства. Когда вступают в силу новые нормативные акты, юридическому отделу необходимо быстро модифицировать формы и процессы согласования. В системе с REM-архитектурой юристы могут добавить нужные поля (например, «Проверка соответствия ФЗ-152») и внедрить новые контрольные точки в маршрут согласования без запросов в ИТ-отдел — департамент может самостоятельно обеспечивать правовую безопасность компании и минимизировать риски, связанные с несоответствием системы актуальным требованиям законодательства.
Финансовые процессы
Финансовый департамент работает с чувствительными данными, требующими строгого контроля доступа и различных форматов для разных операций:
-
Запросы на платежи включают реквизиты, суммы, статьи бюджета, основания для оплаты
-
Согласование бюджетов содержит плановые показатели, сравнение с фактическими и обоснования отклонений
-
Авансовые отчеты требуют детализации расходов, приложенных документов, учета различных валют
REM обеспечивает для финансового департамента исключительно гибкий контроль доступа на уровне моделей и атрибутов. Например, информация о суммах и контрагентах в запросах на платежи может быть видна только финансовому директору и главному бухгалтеру, при этом общий статус запроса доступен всем участникам процесса. При работе с бюджетами REM позволяет настроить доступ таким образом, чтобы руководители подразделений видели только свои статьи расходов, а топ-менеджмент — консолидированные данные.
Интеграция департаментов: сквозные процессы с единой архитектурой
Особую ценность REM приобретает в сквозных процессах, охватывающих несколько департаментов. Например, процесс оформления нового сотрудника включает шаги от HR, ИТ, АХО и бухгалтерии:
-
HR создает профиль сотрудника и инициирует процесс;
-
ИТ подготавливает учетные записи и оборудование;
-
АХО организует рабочее место;
-
бухгалтерия настраивает параметры для расчета зарплаты.
Без REM каждый департамент должен создать свои таблицы и процессы, интеграция и отслеживание данных будет сложнее, так как потребуется разработка и поддержка множества интерфейсов обмена данными между разрозненными системами, что создает технический долг и повышает риск возникновения ошибок при передаче информации. Кроме того, любое изменение в сквозном процессе без REM затрагивает несколько систем одновременно, делая координацию обновлений сложной задачей. С использованием REM-подхода все департаменты работают в единой системе с общей структурой данных, каждый видит только релевантные для его работы атрибуты, при изменении требований одного департамента не нужно перестраивать всю систему.
Итог
Динамическая модель данных и технология REM становятся не просто техническим преимуществом, а стратегическим фактором успеха при масштабировании сервисного подхода в масштабах всего предприятия. Они позволяют преодолеть «бункерную культуру», когда подразделения изолированы друг от друга, и создать единую цифровую среду, где разные департаменты могут эффективно взаимодействовать, сохраняя при этом необходимую автономность.
Выбирая ESM-платформу с поддержкой REM, компании получают инструмент, который растёт вместе с их потребностями и адаптируется к изменениям бизнес-процессов без значительных инвестиций в доработку. Это особенно важно в современных условиях, когда скорость внедрения изменений становится конкурентным преимуществом, а перегруженность ИТ-специалистов достигает критических значений. REM позволяет освободить квалифицированных технических специалистов от рутинных задач кастомизации и перенаправить их потенциал на проекты с высокой бизнес-ценностью.