АЛГОРИТМ РАЗРЕШЕНИЯ КОНФЛИКТОВ ПРИ БРОНИРОВАНИИ ВНУТРЕННИХ ОБЪЕКТОВ ПРЕДПРИЯТИЯ НА ОСНОВЕ ИЕРАРХИИ РОЛЕЙ

Введение

Внутренние ресурсы предприятия, такие как рабочие места, переговорные комнаты, оборудование и специализированные зоны, используются несколькими сотрудниками и подразделениями. При росте числа пользователей и объектов возрастает вероятность пересечения заявок по времени, что приводит к конфликтным ситуациям, дополнительным согласованиям и снижению прозрачности процесса [1–4].

На практике бронирование нередко организуется с помощью таблиц, календарей и неформальных договорённостей. Такой подход может быть приемлем на начальном этапе, однако при масштабировании он становится источником ошибок. Основные недостатки связаны с отсутствием строгой проверки пересечения интервалов, невозможностью формального разграничения доступа к объектам и отсутствием единых правил разрешения конфликтов [1, 3].

Одним из способов формализации правил доступа является ролевая модель. Она позволяет связывать разрешения не непосредственно с пользователями, а с их ролями, что упрощает администрирование и делает систему более устойчивой к организационным изменениям [5, 6]. Однако для систем бронирования одной проверки права доступа недостаточно. Необходимо учитывать случаи, когда объект уже занят, а новая заявка поступает от пользователя с более высоким приоритетом.

В связи с этим возникает задача построения алгоритма, который учитывает временное пересечение бронирований, принадлежность пользователя к допустимой группе доступа и положение его роли в иерархии приоритетов.

Цель статьи — разработка алгоритма разрешения конфликтов при бронировании внутренних объектов предприятия на основе иерархии ролей пользователей.

Постановка задачи

Рассмотрим множество внутренних объектов предприятия O = {o1, o2, …, on}, где каждый объект oi представляет ресурс, доступный для временного использования.

Пусть задано множество пользователей U = {u1, u2, …, um} и множество ролей R = {r1, r2, …, rk}.

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

Бронирование объекта опишем кортежем b = <u, o, ts, te, s>, где u — пользователь, o — объект, ts — время начала, te — время окончания, s — статус бронирования.

Новый запрос задаётся кортежем q = <uq, oq, tsq, teq>. Система должна принять одно из решений: разрешить бронирование, отклонить запрос или выполнить перебронирование.

Конфликт имеет место, если существует активное бронирование того же объекта, для которого интервалы пересекаются: [tsq, teq] ∩ [tsb, teb] ≠ ∅.

Требуется построить алгоритм, который по данным о пользователе, объекте, временном интервале и ролевой конфигурации определяет корректное решение в конфликтной ситуации.

Методы исследования

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

Для каждого объекта определяется группа бронирования G(o). Для пользователя u в пределах данной группы может быть определён уровень приоритета p(u, o). Тогда сравнение прав в конфликтной ситуации выполняется по следующим правилам:

– если p(uq, oq) не определён, доступ запрещается;

– если p(uq, oq) < p(ub, oq), новый запрос отклоняется;

– если p(uq, oq) = p(ub, oq), перебронирование не допускается;

– если p(uq, oq) > p(ub, oq), допускается перебронирование.

На основе этих правил сформирован алгоритм разрешения конфликта.

Алгоритм. Разрешение конфликта бронирования

Входные данные: пользователь uq, объект oq, интервал [tsq, teq].

Выходные данные: решение d ∈ {approve, reject, rebook}.

1. Проверить существование объекта oq. Если объект отсутствует, вернуть reject.

2. Проверить, имеет ли пользователь uq доступ к объекту oq. Если доступа нет, вернуть reject.

3. Найти активные бронирования объекта oq, пересекающиеся с интервалом [tsq, teq].

4. Если пересекающихся бронирований нет, вернуть approve.

5. Для каждого конфликтующего бронирования определить уровень приоритета нового пользователя pq и уровень приоритета текущего владельца бронирования pb.

6. Если pq не определён, вернуть reject.

7. Если существует хотя бы одно бронирование, для которого pq ≤ pb, вернуть reject.

8. Если для всех конфликтующих бронирований выполняется pq > pb, вернуть rebook.

9. Зафиксировать решение в журнале действий и сформировать уведомления.

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

Результаты

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

Рассмотрим несколько типовых сценариев.

Сценарий 1. Отсутствие конфликта.

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

Сценарий 2. Равноправные роли.

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

Сценарий 3. Различие уровней приоритета.

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

С вычислительной точки зрения пусть c — число конфликтующих бронирований, найденных для заданного объекта и интервала. Тогда основная часть алгоритма связана с последовательным сравнением уровней приоритета, а временная сложность составляет O(c).

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

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

Дополнительным результатом является возможность журналирования причин принятого решения. В системе могут фиксироваться следующие варианты:

– отказ из-за отсутствия доступа;

– отказ из-за равного приоритета;

– отказ из-за более низкого приоритета;

– успешное создание бронирования;

– успешное перебронирование.

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

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

Обсуждение

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

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

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

Предложенный подход может быть расширен. В частности, в алгоритм могут быть добавлены проверки по подразделениям, временным ограничениям, типам объектов и дополнительным условиям согласования. При этом базовая логика сравнения приоритетов сохраняется.

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

Ещё одним преимуществом предложенного подхода является его пригодность для поэтапного расширения. На первом этапе алгоритм может применяться для базового набора объектов и ролей. В дальнейшем в него могут быть включены дополнительные признаки, например принадлежность пользователя к подразделению, допустимость использования объекта только в рабочие часы, ограничения по типу деятельности или необходимость предварительного согласования со стороны ответственного сотрудника. При этом базовая схема сравнения приоритетов остаётся неизменной, что подтверждает модульный характер предложенного решения.

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

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

Алгоритм применим не только к рабочим местам и переговорным комнатам, но и к иным внутренним объектам предприятия: оборудованию, лабораторным стендам, служебным помещениям, транспорту и другим корпоративным ресурсам.

Заключение

Разработан алгоритм разрешения конфликтов при бронировании внутренних объектов предприятия на основе иерархии ролей пользователей. Алгоритм учитывает временное пересечение бронирований, принадлежность пользователя к группе доступа и его уровень приоритета. Это позволяет принимать формально обоснованные решения о создании, отклонении или перебронировании заявки.

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

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