Разбор 5 типовых проблем согласования документов медицинской организации

Проблематика согласования документов | перейти к решению Почему традиционные процессы снабжения дают сбой — и как МЕДЕРП решает эти проблемы с помощью управляемой валидации согласования.

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

Как это выглядит на практике:

• Правила проверки жёстко зашиты в коде конфигурации.
• Для изменения любого условия — превышение лимита, контроль заполнения реквизита — требуется разработчик 1С.
• Один и тот же набор проверок применяется ко всем документам независимо от их типа и суммы.
• Этапы согласования не различаются по составу проверок — экономист и специалист КС видят одни и те же ошибки.
• При срабатывании проверки пользователь видит общее сообщение «Ошибка в данных» без указания на конкретную проблему.
• Некритичные нарушения (например, отсутствие комментария) блокируют согласование так же, как и критичные.
• Изменение регламента требует обновления релиза и занимает дни, а иногда и недели.

Результат — 5 типовых проблем, которые мы подробно разберем ниже. Каждая из них — следствие отсутствия гибкой и настраиваемой системы валидации. И каждая из этих проблем имеет системное решение при внедрении механизма «Управляемая валидация согласования» в составе медицинской ERP-системы МЕДЕРП, которая обеспечивает комплексное снабжение медицинских организаций.

Жёсткая логика проверок — зависимость от разработчиков

Суть проблемы: правила проверки документов зашиты непосредственно в код конфигурации. Каждый раз, когда меняется регламент (новый лимит подразделения, изменение порядка расчёта, появление нового обязательного реквизита), приходится привлекать разработчиков 1С, вносить изменения в код, тестировать и обновлять релиз. Это напрямую влияет на управление снабжением, делая его инертным и негибким.

Почему так происходит? Традиционная архитектура предполагает, что бизнес-логика «зашивается» в модули документов и обработок. Это создаёт надёжную, но неповоротливую систему. Любое изменение требует квалифицированного программиста, а цикл «задача → доработка → тестирование → релиз» занимает от нескольких дней до нескольких недель. При этом бизнес-требования могут меняться значительно быстрее, а современное материальное снабжение требует оперативной реакции на изменения рыночной ситуации.

Последствия для организации:

• Долгий цикл внесения изменений — новые регламенты внедряются с опозданием.
• Высокая стоимость доработок — работа специалистов 1С стоит дорого (3000–5000 т.р. за час работы специалиста), а частые изменения делают её непредсказуемой.
• Зависимость от конкретных исполнителей — если разработчик уволился или занят, изменение может быть отложено на неопределённый срок.
• Риск внесения ошибок — каждое изменение кода потенциально может сломать что-то ещё.
• Отсутствие гибкости — бизнес-аналитик не может оперативно отреагировать на новые требования бизнеса.

Одинаковые проверки для всех этапов и пользователей

Суть проблемы: традиционные системы согласования не умеют дифференцировать проверки. На этапе экономиста нужен контроль лимитов, соответствие видов затрат финансовой аналитике (КОСГУ, КВР), допустимость финансирования для выбранных подразделений или позиций. На этапе юриста — проверка наличия ставок НДС и комплектности приложенных документов. На этапе специалиста контрактной службы — контроль наличия ОКПД2, КТРУ, корректности способов закупок. На этапе подписания договора — соответствие единиц измерения, заполненного договора. Но в типовых решениях все видят одно и то же, что делает учёт снабжения избыточно зашумленным.

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

Последствия для организации:

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

Неинформативные ошибки — «что-то пошло не так»

Суть проблемы: при срабатывании проверки пользователь видит общее сообщение «Ошибка в данных», «Документ не прошёл проверку» или, в лучшем случае, «Превышен лимит». Но что именно не так? Какая позиция? Какой реквизит? Где и что нужно исправить? Ответов нет. Это серьёзно замедляет процессы снабжения, так как каждый инцидент требует ручного разбора.

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

Последствия для организации:

• Потеря времени пользователя — он вынужден «вслепую» искать причину отказа.
• Дополнительные звонки в поддержку — «а что значит эта ошибка?».
• Невозможность автоматической обработки — внешние системы не могут распознать причину отказа (нет машинного кода).
• Снижение доверия к системе — пользователи считают, что «система глючит», а не проверяет данные.
• Ручной поиск ошибок — в закупке на тысячу позиций найти «ту самую» практически невозможно.

Нет разницы между критичными и некритичными нарушениями

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

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

Последствия для организации:

• Блокировка срочных закупок — из-за формальных, а не содержательных нарушений.
• Демотивация персонала — «система мешает работать».
• Создание «обходных путей» — пользователи начинают искать способы «обмануть» систему, что снижает качество данных.
• Невозможность настроить гибкую маршрутизацию — например, отправлять документ на доработку целевым пользователям при незначительных нарушениях.

Длительное внедрение новых регламентов — дни и недели вместо минут

Суть проблемы: время — это деньги. Особенно в работе снабжения, где задержка может привести к срыву поставки, простою оборудования или необходимости срочного «ручного режима». Когда новое требование регулятора или внутренний регламент требует добавить проверку, традиционные системы требуют доработки конфигурации.

Цикл «постановка задачи → разработка → тестирование → релиз» в государственных и бюджетных учреждениях может занимать от 3 до 10 дней, а иногда и больше. Привлечение сторонних подрядчиков может занять месяцы, особенно если требуется заключение нового договора. Это недопустимо в современных условиях, когда требования к организации снабжения меняются быстро.

Последствия для организации:

• Несвоевременное соблюдение регламентов — пока доработают, новое требование уже изменилось.
• Ручная работа на «переходном периоде» — пока проверка не внедрена, её приходится выполнять вручную (или не выполнять) в записных книжках или Excel-таблицах.
• Накопление «технического долга» — каждый раз дорабатывать конфигурацию, усложнять её, накапливать изменения, а при обновлениях релиза — стараться не затерять.
• Высокая стоимость владения — частые доработки требуют постоянного участия разработчиков и зависимость от них (при смене подрядчика — риск потери функциональности).
• Риск ошибок при обновлении — каждое накопленное изменение конфликтует с типовым функционалом.

Как МЕДЕРП решает проблемы согласования

МЕДЕРП решает описанные проблемы комплексного снабжения за счёт механизма «Управляемая валидация согласования», который изначально проектировался как гибкая и настраиваемая система проверок, а не очередной «жёсткий» модуль. Это позволяет вывести управление снабжением на принципиально новый уровень оперативности.

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

• Настраиваемые контроли без разработки — бизнес-аналитик или администратор Центра самостоятельно создаёт правила проверки через справочник «Настраиваемые контроли согласования». Текст запроса на языке 1С, параметры, режимы — всё настраивается через пользовательский интерфейс.
• Дифференциация по этапам и группам — в маршруте согласования для каждого этапа и исполнителя фиксируется свой набор контролей. Экономист видит финансовые проверки, юрист — юридические, руководитель — контроль обоснованности. Каждый на своём этапе.
• Информативные HTML-ошибки — при срабатывании контроля система выводит HTML-сообщение с таблицей некорректных данных, кодом ошибки и рекомендациями по исправлению. Пользователь сразу понимает, что не так. Бизнес-аналитик может дополнить HTML-шаблон статичной информацией с рекомендуемыми действиями в системе снабжения.
• Три режима реакции — «Блокировать» (остановка согласования), «Уведомлять» (фиксация нарушения, но продолжение), «Игнорировать» (временное отключение). Некритичные нарушения не блокируют процесс, но выводятся для пользователя.
• Мгновенное внедрение изменений — новый контроль или изменение существующего вступают в силу сразу после сохранения в справочнике и фиксации в маршруте согласования. Никаких доработок конфигурации, никакого обновления релиза. Минуты вместо дней.

• Редактор HTML производимого контроля мед. ERP МЕДЕРП
• Отображение контроля для пользователя в ERP МЕДЕРП

Детальный алгоритм работы механизма:

• Пользователь нажимает «Согласовать» или «Согласовать с замечаниями».
• Система выполняет стандартные встроенные проверки документа (заполненность реквизитов, контроль дат, ссылочная целостность, превышение плана ФХД, заполненность спецификации и пр.).
• Определяет текущий этап маршрута и группу пользователя.
• Из раздела «Управляемые контроли» выбираются все контроли для данного этапа и группы.
• Для каждого контроля:
  • если режим «Игнорировать» — проверка пропускается;
  • если режим «Уведомлять» — выполняется, ошибка выводится в формате HTML-сообщения, согласование может быть продолжено;
  • если режим «Блокировать» — выполняется, при ошибке согласование прерывается с выводом HTML-сообщения.
• После прохождения всех контролей документ переходит на следующий этап.

Результат: время внесения изменений сокращается с дней до минут. Согласование становится прозрачным, проверки — точными и контекстными, ошибки — информативными, а пользователи перестают «воевать» с системой. В итоге материальное снабжение и учёт снабжения становятся по-настоящему управляемыми процессами.

Часто задаваемые вопросы об управляемой валидации согласования

Что такое управляемая валидация согласования?

Управляемая валидация согласования — это механизм автоматической проверки документов перед принятием решения. Правила проверки (контроли) настраиваются администратором или бизнес-аналитиком через справочник «Настраиваемые контроли согласования» и не требуют доработки конфигурации. Контроли фиксируются в маршрутах согласования и привязываются к конкретному этапу и группе пользователей, а также имеют разные режимы реакции — блокировать, уведомлять или игнорировать.

Чем управляемая валидация отличается от встроенных проверок 1С?

Встроенные проверки 1С «зашиты» в код конфигурации. Их изменение требует работы программиста и обновления релиза (расширения). Управляемая валидация хранит правила проверки в справочнике и выполняет их динамически. Изменить правило можно через интерфейс за несколько минут, без участия разработчика. Это критически важно для эффективной организации снабжения в быстро меняющейся среде.

Какие режимы выполнения контролей поддерживаются?

Поддерживаются три режима: «Блокировать» (при ошибке согласование прерывается), «Уведомлять» (ошибка выводится, но согласование может быть продолжено) и «Игнорировать» (контроль не происходит). Это позволяет гибко реагировать на критические и некритические нарушения.

Можно ли привязать контроли к разным этапам согласования?

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

Как формируются сообщения об ошибках?

При срабатывании контроля система генерирует HTML-сообщение с таблицей некорректных данных, кодом ошибки (код реестра ошибок портала mederp.ru) и расшифровкой. Поддерживаются макросы подстановки: {{Наименование}}, {{ИдентификаторКонтроля}}, {{ПредметСогласования}}, {{РезультатЗапроса}}. Шаблон сообщения настраивается в справочнике.

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

Да. Для сценариев, которые невозможно реализовать через запрос на языке 1С (циклические проверки, вызов внешних веб-сервисов, сложные алгоритмы), предусмотрен режим использования переопределяемой функции. В этом случае вместо текста запроса вызывается предопределённая функция из общего модуля. В таких случаях потребуется привлечение квалифицированных разработчиков 1С для реализации кастомной логики.

Проблема → решение в МЕДЕРП

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

• Жёсткая логика проверок
  • Суть: Правила зашиты в код, изменение только через разработчика.
  • Решение: Справочник «Настраиваемые контроли согласования» — настройка через интерфейс без программирования.
• Одинаковые проверки для всех этапов
  • Суть: Все видят одни и те же ошибки, нет контекста.
  • Решение: Раздел «Управляемые контроли» в маршруте — привязка контролей к этапу и группе пользователей.
• Неинформативные ошибки
  • Суть: «Ошибка в данных» — непонятно, что исправлять.
  • Решение: HTML-шаблоны с макросами, таблица некорректных данных, код ошибки реестра ошибок портала mederp.ru.
• Нет градации критичности
  • Суть: Любая ошибка блокирует согласование.
  • Решение: Три режима выполнения — «Блокировать», «Уведомлять», «Игнорировать».
• Длительное внедрение изменений
  • Суть: Доработка конфигурации → тестирование → релиз = дни и недели.
  • Решение: Изменение в справочнике вступает в силу мгновенно — минуты вместо дней.