Стандартизация информационных потоков цифровой организации

В цифровой организации результат деятельности зависит не только от качества услуги или продукта, но и от того, насколько управляемо проходят данные между ролями, подразделениями и информационными системами. Когда информационный поток не выделен в самостоятельный объект управления, возникают типовые проблемы: разнородные трактовки сроков, несопоставимые показатели, размытая ответственность за данные и слабая доказательная база внутреннего аудита. С позиции системы менеджмента качества это означает неполную реализацию процессного подхода, поскольку ISO 9001 требует определять процессы, их входы и выходы, критерии результативности, методы мониторинга и улучшения¹.

Краткий обзор литературы

Нормативная база стандарта формируется на стыке нескольких контуров. ISO/IEC 25012 задает модель качества данных, ISO 8000-61 описывает процессы управления качеством данных, ISO 31000 вводит риск-ориентированный подход². Для цифровых потоков к этому должен добавляться слой воспроизводимого журналирования событий; такую основу дает IEEE 1849-2023, закрепляющий XES (eXtensible Event Stream) как стандартизованный формат обмена журналами событий³. Публикации последних лет показывают, что регулярный мониторинг качества данных и качества журналов событий прямо влияет на достоверность анализа процессов и управленческих выводов [1–3]; в работах российских авторов чаще рассматривается организация в целом, а не информационный поток как самостоятельный объект регламентации [4, 5].

Предлагается компактная и прикладная методика стандартизации управления информационными потоками в цифровой организации. В статье под стандартом управления информационными потоками (далее — стандарт) понимается стандарт организации (СТО), устанавливающий требования к процессам, продукции и услугам. В центре внимания находятся артефакты, пригодные для включения в СТО: паспорт потока, протокол измерения ключевых показателей деятельности, спецификация логирования, контрольные точки и чек-лист внутреннего аудита. Контур стандартизации управления информационным потоком представлен на рис. 1.

Рис. 1. Контур стандартизации управления информационным потоком

Методика стандартизации управления информационными потоками

Определение и классификация потока

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

Рис. 2. Структура паспорта информационного потока

Для целей стандарта достаточно классификации по четырем измерениям: критичность, тип данных, режим передачи и уровень защищенности. Критичность отражает последствия нарушения потока для процесса; тип данных характеризует содержание передаваемой информации; режим передачи показывает чувствительность к задержкам; уровень защищенности задает требования к доступу, обработке и хранению. Такая схема, хотя и предельно компактна, работает вполне надежно: именно она позволяет увязать частоту контроля и состав ключевых показателей деятельности с реальным управленческим риском. Чем выше критичность потока и жестче требования к защищенности, тем чаще необходим мониторинг и тем строже должны быть пороговые значения по своевременности, качеству данных и рискам.

Артефакты СТО по управлению информационными потоками

Предполагается, что стандарт опирается на пять обязательных артефактов.

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

Второй артефакт — протокол измерения ключевых показателей деятельности. Он задает единые правила расчета. Для каждого показателя в нем указываются наименование, формула, источник данных, окно расчета, порог, реакция по корректирующим и предупреждающим действиям (CAPA), ответственный и перечень подтверждающих материалов. Структура такого протокола показана на рис. 3.

Третий элемент — спецификация логирования. Она задает минимально обязательный состав полей журнала событий: case_id — идентификатор экземпляра потока; activity — операция или этап процесса; timestamp_start / end — время начала и завершения операции; resource / role — исполнитель или организационная роль; outcome — результат выполнения операции; dq_flags — признаки дефектов качества данных; security_class — класс защищенности и режим доступа; channel — канал передачи или источник записи. Минимальный формат хранения и обмена данными предлагается фиксировать как CSV (Comma-Separated Values, значения, разделенные запятыми). Для межсистемного обмена и последующего анализа процессов целесообразно предусматривать экспорт в XES. Базовая структура спецификации приведена в табл. 1.

Рис. 3. Структура протокола измерения ключевых показателей деятельности

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

Таблица 1. Минимальная спецификация логирования

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

Рис. 4. Контрольные точки типового потока

Рис. 5. Структура чек-листа внутреннего аудита

Роли и распределение ответственности

Для практического применения стандарта достаточно шести ролей. Речь идет о владельце потока, владельце данных, координаторе качества данных (data steward), ИТ-сервисе, службе информационной безопасности и службе качества либо системы менеджмента качества. Такое распределение, при всей его компактности, закрывает основные контуры управления.

Рис. 6. Макет панели мониторинга владельца потока
Примечание. Используемые сокращения: T_p90 — 90-й перцентиль времени прохождения кейса; DQ — дефекты качества данных; SLA — уровень сервиса; CAPA — корректирующие и предупреждающие действия.

Рис. 7. Регламентный процесс внедрения стандарта

Владелец потока отвечает за соблюдение соглашений об уровне сервиса, результативность процесса и запуск корректирующих действий при отклонениях. На владельце данных закрепляются правила качества данных и перечень допустимых исключений. Координатор качества данных ведет операционный контроль, сопровождает справочники и отслеживает типовые дефекты. ИТ-сервис обеспечивает журналирование, доступность и выгрузку данных. Служба информационной безопасности контролирует режим доступа и меры защиты. Служба качества, в свою очередь, отвечает за аудит, сопоставимость доказательной базы и пересмотр регламента. В такой схеме роли не дублируют друг друга, что для стандарта организации принципиально: размытая ответственность почти всегда приводит к размытым показателям. Показатели владельца потока представлены на рис. 6.

Внедрение стандарта управления информационным потоком целесообразно выполнять поэтапно: от идентификации и классификации потока к формированию паспорта, установлению ключевых показателей деятельности и соглашения об уровне сервиса, настройке логирования, определению контрольных точек, пилотному мониторингу и последующему аудиту. Такая последовательность позволяет вводить стандарт без полной перестройки действующих информационных систем и обеспечивает управляемый переход к регулярному контролю. Регламентный процесс внедрения стандарта представлен на рис. 7.

Для единообразного применения предлагаемого стандарта используются базовые обозначения и термины, связанные с управлением потоком, качеством данных, сроками и рисками⁴. Основные термины и обозначения, используемые в статье, приведены в табл. 2.

Практическая применимость стандарта определяется не только составом документов, но и едиными правилами измерения показателей. Состав ключевых показателей деятельности, источники данных, пороговые значения и ответственность за контроль представлены в табл. 3.

Таблица 2. Основные обозначения и термины стандарта управления потоком

Таблица 3. KPI информационного потока: расчет, источник, порог, ответственность

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

Таблица 4. Форма паспорта информационного потока

Мини-кейс на открытом журнале событий

Для демонстрации воспроизводимого извлечения ключевых показателей деятельности предлагается использовать открытый журнал событий BPI Challenge 2013 по управлению инцидентами [6]. Реальные данные приняты как состояние «до стандартизации», а сценарий «после внедрения стандарта» представлен как расчетный пример ожидаемого эффекта.

По опубликованному распределению времени обработки доля кейсов, закрытых быстрее 24 часов, составляет около 28,5%, а T_p90 находится на уровне около 23 суток. Это показывает наличие тяжелого хвоста распределения и подтверждает, что контроль только по средним значениям не отражает реальный управленческий риск. В расчетном сценарии после внедрения стандарта предполагается снижение доли дефектов качества данных, повторной обработки и повторных переназначений за счет обязательных полей формы, контроля маршрутизации, закрепления владельца потока и выделения контрольных точек. Сравнение сценариев приведено в табл. 5.

Таблица 5. Результаты мини-кейса «до/после внедрения стандарта»

Примечание. Показатели T_p90 и SLA rate в колонке «До внедрения» получены по авторскому расчету на основе журнала BPI Challenge 2013 [6]. Значения представлены как расчетный сценарий ожидаемого эффекта от внедрения стандарта.

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

Обсуждение

Предлагаемая методика разделяет управление потоком и управление информационной системой. Это различие принципиально: один и тот же поток может проходить через несколько систем и владельцев инфраструктуры, однако для потребителя качества решающими остаются соблюдение срока, полнота данных и предсказуемость результата. Поэтому в стандарте основным объектом учета выбран паспорт потока, а не описание ИТ-ландшафта.

Отдельного внимания требует журналирование. Во многих организациях журналы событий по-прежнему воспринимаются как технический материал, нужный главным образом для сопровождения сервисов и разбора инцидентов. Между тем исследования показывают, что дефекты временных меток, пропуски, дублирование записей и некорректные атрибуты делают управленческие выводы нестабильными [2, 3]. Отсюда вытекает практическое требование: качество журналов должно входить в контур внутреннего аудита наравне с качеством документов и учетных записей.

С объемом методики связана и другая проблема: для внедрения не нужен громоздкий пакет документов. Чрезмерно разросшийся регламент быстро перестает работать как практический инструмент. Достаточным является минимальный набор: паспорт потока, протокол измерения ключевых показателей деятельности, чек-лист аудита, спецификация логирования и перечень контрольных точек. Именно этот минимум позволяет перейти от разрозненных локальных практик к единому стандарту без избыточной документации.

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

Заключение

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

Нормативная база, основанная на ISO 9001, ISO/IEC 25012, ISO 8000-61, ISO 31000 и IEEE 1849-2023 (XES), связывает процессный подход, требования к качеству данных, риск-ориентированное управление и журналирование событий.

Анализ показывает, что контроль только по средним значениям недостаточен, тогда как использование 90-го перцентиля срока обработки и доли случаев, выполненных в установленный срок, делает мониторинг более чувствительным к реальному риску.

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

ЛИТЕРАТУРА

1. Ehrlinger L., Woess W. A Survey of data quality measurement and monitoring tools. Frontiers in Big Data, 2022, no. 5, 850611. DOI: 10.3389/fdata.2022.850611.
2. Martin N., Van Houdt G., Janssenswillen G. DaQAPO: supporting flexible and fine-grained event log quality assessment. Expert Systems with Applications, 2022, vol. 191, no. 7, 116274. DOI: 10.1016/j.eswa.2021.116274.
3. Dakic D., Stefanovic D., Vuckovic T., et al. Event log data quality issues and solutions. Mathematics, 2023, vol. 11, no. 13, 2858. DOI: 10.3390/math11132858.
4. Черняховская Л.Р., Мухаметьянова Р.И., Сиротина А.А. Улучшение системы менеджмента качества промышленных предприятий с помощью использования корпоративных знаний // Онтология проектирования. 2023. Т. 13. № 2. С. 274–281 (на англ. яз.). DOI: 10.18287/2223-9537-2023-13-2-274-281.
5. Кальганов И.С. Оценка результатов функционирования электронного правительства и цифровизации государственных услуг // Интеллект. Инновации. Инвестиции. 2024. № 1. С. 29–41. DOI: 10.25198/2077-7175-2024-1-29.
6. Steeman W. BPI Challenge 2013, incidents. Dataset. Version 1. 4TU.ResearchData, 2013. DOI: 10.4121/uuid:500573e6-accc-4b0c-9576-aa5468b10cee.

¹ ГОСТ Р ИСО 9001–2015 «Системы менеджмента качества. Требования» (ISO 9001:2015).
² ISO/IEC 25012:2008 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Data quality model. ISO/IEC. 2008. ГОСТ Р 71487.1–2024 «Цифровая промышленность. Качество промышленных данных. Часть 61. Управление качеством промышленных данных. Базовая модель процесса» (ISO 8000-61:2016). ГОСТ Р ИСО 31000–2019 «Менеджмент риска. Принципы и руководство» (ISO 31000:2018).
³ IEEE Std 1849-2023. IEEE Standard for eXtensible Event Stream (XES) for Achieving Interoperability in Event Logs and Event Streams. IEEE Standards Association. 2023.
⁴ ГОСТ 33707-2016 «Информационные технологии. Словарь» (ISO/IEC 2382:2015).
⁵ NIST/SEMATECH e-Handbook of Statistical Methods. Percentile. URL: https://www.itl.nist.gov/div898/software/dataplot/refman2/auxillar/percenti.htm. Process Mining Book 3.1. Analyzing Cases. URL: https://fluxicon.com/book/read/casesview/.

01.04.2026

---

448

Поделиться: