Компании, внедряющие 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

Что такое REM и как он позволяет строить гибкие ESM-системы?

Расширенная модель записи (Record Extended Model, REM) — это архитектурный подход к организации данных, который позволяет динамически расширять основную структуру без её изменения. В основу REM заложен классический подход EAV.

REM решает фундаментальную проблему корпоративных информационных систем — необходимость гибко адаптироваться к разнообразным потребностям разных департаментов без усложнения структуры данных.

Основные компоненты REM-архитектуры

REM состоит из трех основных компонентов, которые в совокупности обеспечивают гибкость и масштабируемость системы:

  1. Модель — определяет набор дополнительных полей, которые будут связаны с записями в основной таблице. Для ESM-системы моделью может быть, например, «Запрос на выдачу оборудования» или «Заказ расходных материалов».
  2. Атрибуты — отдельные поля, хранящие специфическую информацию. Для запроса на выдачу оборудования это могут быть «Тип устройства», «Модель оборудования» и «Количество».
  3. Коллекции атрибутов — логически сгруппированные наборы полей, которые можно использовать в разных моделях. Например, коллекция «Доставка» может содержать атрибуты «Адрес доставки», «Предпочтительная дата доставки».

Структурная схема компонентов REM

Как 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-технология трансформирует рабочие процессы и повышает эффективность взаимодействия.

Сервисный портал в SimpleOne

HR-автоматизация

Отдел кадров работает с разнородными процессами, каждый из которых требует уникального набора полей:

  • Заявления на отсутствие требуют указания дат, типа отсутствия (отпуск, командировка, больничный) и замещающих сотрудников.

  • Запросы на выдачу документов содержат перечень необходимых документов, цель их получения и формат выдачи.

  • Оформление новых сотрудников включает поля для данных о позиции, зарплате, требуемом оборудовании.

Если представить эти поля в одной таблице, система станет громоздкой и неудобной в администрировании. REM позволяет HR-отделу хранить все запросы в единой таблице, при этом каждый тип запроса будет получать только нужные ему атрибуты, также быстро создавать новые виды заявок без изменения структуры таблицы и настраивать формы для разных ролей — руководитель видит один набор полей, сотрудник — другой, HR-специалист — третий.

Автоматизация юридического отдела

Юридический отдел работает с множеством типов документов, требующих разных атрибутов и маршрутов согласования:

  • Договоры с контрагентами требуют информации о контрагенте, суммах, сроках и особых условиях

  • Правовые заключения содержат иной набор атрибутов, включая правовые риски и рекомендации

  • Доверенности содержат информацию о сроках, полномочиях и представителях

Применение REM в юридическом департаменте позволяет создавать гибкие маршруты согласования документов в зависимости от их типа, использовать общие коллекции атрибутов (например, «Контрагент») для разных типов документов.

REM даёт возможность быстро адаптироваться при изменениях законодательства. Когда вступают в силу новые нормативные акты, юридическому отделу необходимо быстро модифицировать формы и процессы согласования. В системе с REM-архитектурой юристы могут добавить нужные поля (например, «Проверка соответствия ФЗ-152») и внедрить новые контрольные точки в маршрут согласования без запросов в ИТ-отдел — департамент может самостоятельно обеспечивать правовую безопасность компании и минимизировать риски, связанные с несоответствием системы актуальным требованиям законодательства.

Финансовые процессы

Финансовый департамент работает с чувствительными данными, требующими строгого контроля доступа и различных форматов для разных операций:

  • Запросы на платежи включают реквизиты, суммы, статьи бюджета, основания для оплаты

  • Согласование бюджетов содержит плановые показатели, сравнение с фактическими и обоснования отклонений

  • Авансовые отчеты требуют детализации расходов, приложенных документов, учета различных валют

REM обеспечивает для финансового департамента исключительно гибкий контроль доступа на уровне моделей и атрибутов. Например, информация о суммах и контрагентах в запросах на платежи может быть видна только финансовому директору и главному бухгалтеру, при этом общий статус запроса доступен всем участникам процесса. При работе с бюджетами REM позволяет настроить доступ таким образом, чтобы руководители подразделений видели только свои статьи расходов, а топ-менеджмент — консолидированные данные.

Интеграция департаментов: сквозные процессы с единой архитектурой

Особую ценность REM приобретает в сквозных процессах, охватывающих несколько департаментов. Например, процесс оформления нового сотрудника включает шаги от HR, ИТ, АХО и бухгалтерии:

  1. HR создает профиль сотрудника и инициирует процесс;

  2. ИТ подготавливает учетные записи и оборудование;

  3. АХО организует рабочее место;

  4. бухгалтерия настраивает параметры для расчета зарплаты.

Без REM каждый департамент должен создать свои таблицы и процессы, интеграция и отслеживание данных будет сложнее, так как потребуется разработка и поддержка множества интерфейсов обмена данными между разрозненными системами, что создает технический долг и повышает риск возникновения ошибок при передаче информации. Кроме того, любое изменение в сквозном процессе без REM затрагивает несколько систем одновременно, делая координацию обновлений сложной задачей. С использованием REM-подхода все департаменты работают в единой системе с общей структурой данных, каждый видит только релевантные для его работы атрибуты, при изменении требований одного департамента не нужно перестраивать всю систему.

Итог

Динамическая модель данных и технология REM становятся не просто техническим преимуществом, а стратегическим фактором успеха при масштабировании сервисного подхода в масштабах всего предприятия. Они позволяют преодолеть «бункерную культуру», когда подразделения изолированы друг от друга, и создать единую цифровую среду, где разные департаменты могут эффективно взаимодействовать, сохраняя при этом необходимую автономность.

Выбирая ESM-платформу с поддержкой REM, компании получают инструмент, который растёт вместе с их потребностями и адаптируется к изменениям бизнес-процессов без значительных инвестиций в доработку. Это особенно важно в современных условиях, когда скорость внедрения изменений становится конкурентным преимуществом, а перегруженность ИТ-специалистов достигает критических значений. REM позволяет освободить квалифицированных технических специалистов от рутинных задач кастомизации и перенаправить их потенциал на проекты с высокой бизнес-ценностью.

Реклама ООО «СИМПЛ 1», ИНН: 9725013892