
Использовать этот шаблон
Четкая ИТ-политика закупок контролирует расходы, управляет рисками и гарантирует, что каждая ИТ-покупка соответствует требованиям безопасности и комплаенса. С Trupeer вы можете сэкономить часы на написании политики, начав с бесплатного шаблона ИТ-политики закупок, настроив его с помощью ваших бренд-гайдлайнов и превратив политику в видеообзор, который сотрудники и поставщики быстро поймут.
Что такое ИТ-политика закупок и чем она не является
ИТ-политика закупок — это письменное правило, которое определяет, кто может обязать компанию перед технологическим поставщиком, что нужно проверить до принятия такого обязательства и что происходит с отношениями после этого. Это не процесс закупки, не список поставщиков и не договор — все это находится дальше по цепочке.
Также это не общая политика закупок с добавлением слова «ИТ» перед ней. Общая закупка предполагает, что приобретаемая вещь поставляется один раз, где-то хранится и амортизируется. Технологии ломают это предположение четыре раза. Они обновляются сами: обязательство на три года подписывается один раз и оплачивается тридцать шесть раз без повторного согласования. Они хранят ваши данные: покупка передает записи клиентов или сотрудников третьей стороне по цене, не имеющей отношения к ценности того, что вы передали. Это может быть бесплатно — и бесплатный инструмент проходит любой порог расходов, когда-либо прописанный в политике. И это не «умирает»: оборудование списывается, а программное обеспечение продолжает выставлять счета после того, как человек, выбравший его, ушел из компании.
Почему большинство ИТ-политик закупок не попадает в деньги
Почти каждый шаблон политики закупок имеет одну и ту же форму: цель, область применения, роли, пороги, матрица согласований, исключения. Матрица согласований всегда привязана к одному числу — сколько это стоит. Такая конструкция предполагает, что дорогостоящий момент и рискованный момент — это один и тот же момент. В ИТ это почти никогда не так.
Дорогостоящий момент — это продление, потому что продления происходят автоматически по цене, которую задает поставщик, по количеству мест, которое считает поставщик, и без участия человека, который бы принимал решения. За пятилетние отношения первоначальная покупка обычно оказывается самым маленьким решением в цепочке и единственным, которое кто-то действительно проверял.
Рискованный момент — это данные. Двенадцатидолларовый инструмент для заметок на пользователя, который загружает записи встреч, несет больше рисков, чем шестидесятитысячный массив хранения, который никогда не покидает здание. Пороги расходов направляют массив к CFO, а инструмент для заметок — к никому.
Поэтому этот шаблон делает две вещи иначе. Он маршрутизирует запросы по двум осям — расходам и риску для данных — вместо одной. И он рассматривает продление как новое решение о закупке, а не как бухгалтерское событие. Все остальное в нем стандартно, а стандарт — это нормально. Важны части: таблица маршрутизации, пункт 9 и реестр.
Как настроить этот шаблон в Trupeer
Шаг 1: Откройте раздел «Templates»
Перейдите в раздел Templates из главного меню.

Шаг 2: Выберите и откройте шаблон
Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

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

Шаг 4: Отредактируйте шаблон
Нажмите Edit, чтобы начать изменять выбранный шаблон.

В редакторе вы можете:
Добавлять новые разделы
Определять или обновлять правила форматирования
Добавить логотип и настроить его положение и связанные параметры
Шаг 5: Сохраните настроенный шаблон
После того как вы внесете все необходимые изменения, нажмите Save, чтобы сохранить обновленный шаблон как свой.

Шаг 6: Предпросмотр и точная настройка шаблона
Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте Preview.

На экране предпросмотра вы можете продолжить вносить изменения напрямую при необходимости, чтобы шаблон выглядел ровно так, как вы хотите.
С шаблоном политики ИТ-закупок вы можете:
Экономить время на написании: Пропустите пустую страницу — структура уже создана под ИТ-закупки.
Контролировать расходы: Встроенные пороги согласований предотвращают несанкционированные покупки.
Оставаться в бренде: Применяйте логотип, шрифты и цвета с помощью бренд-набора Trupeer.
Управлять рисками поставщиков: Встроенные критерии оценки безопасности и комплаенса.
Быть готовыми к аудиту: Соответствие SOC 2, ISO 27001 и аналогичным фреймворкам.
Достигать глобальных команд: Переводите политики закупок на 65+ языков в один клик.
Как маршрутизировать согласования, когда самый дешевый инструмент несет максимум риска
Таблица маршрутизации ниже заменяет матрицу порога в одной колонке. Читайте по горизонтали — расходы, по вертикали — риск для данных, и берите ячейку, куда вы попадаете. Правило, которое делает это работающим, заключается в том, что риск для данных может повысить уровень согласования, но никогда не понизить его. Бесплатный инструмент, который касается персональных данных клиентов, направляется на проверку безопасности, и то, что он ничего не стоит, не имеет значения.
Ежегодные обязательные расходы | Нет данных компании | Только внутренние данные | Персональные данные (клиента или сотрудника) | Регулируемые данные (здоровье, платежи, финансы, государство) |
|---|---|---|---|---|
Ноль, включая бесплатные тарифы | Линейный руководитель | Владелец ИТ | Проверка безопасности и владелец ИТ | Полная проверка |
Менее 2,000 | Линейный руководитель | Владелец ИТ | Проверка безопасности и владелец ИТ | Полная проверка |
2,000 to 15,000 | Владелец ИТ | Владелец ИТ и Финансы | Проверка безопасности, владелец ИТ, Финансы | Полная проверка |
15,000 to 75,000 | Владелец ИТ и Финансы | Проверка безопасности, владелец ИТ, Финансы | Полная проверка | Полная проверка |
Свыше 75,000 | Полная проверка | Полная проверка | Полная проверка | Полная проверка |
Полная проверка означает, что Security, Legal, Finance и руководитель по технологиям рассматривают вопрос вместе — до любой подписи или ввода данных карты.
Валюта и диапазоны — ваши, и они гораздо менее важны, чем колонки. Если вы не измените здесь ничего другого, измените пороги с одной оси на две. Также обратите внимание, что «ежегодные обязательные расходы» — это сумма за двенадцать месяцев, а не размер операции. Плата в размере четырехсот сорока пяти долларов в месяц — это обязательство в пять тысяч триста сорок долларов, и политики, которые читают транзакцию, а не обязательство, — причина того, что произошло в примере ниже.
Шаблон политики ИТ-закупок, часть первая: цель, область применения, роли
Скопируйте отсюда. Замените все, что в квадратных скобках.
1. Цель
Эта политика описывает, как [Company] оценивает, утверждает, покупает, продлевает и выводит из эксплуатации продукты и услуги в области информационных технологий. Она существует, чтобы гарантировать, что расходы на технологии осознанны, что данные, передаваемые третьим сторонам, оцениваются до передачи, и что у каждого активного поставщика есть назначенный владелец внутри компании.
2. Область применения
Эта политика распространяется на всех сотрудников, подрядчиков и временный персонал [Company], а также на все приобретения технологий независимо от стоимости или способа оплаты. Она охватывает подписки и лицензии на программное обеспечение, облачные и хостинговые услуги, оборудование и устройства, профессиональные услуги и услуги по внедрению, каналы данных и контента, а также инструменты разработчика и API.
Эта политика также распространяется на продукты, предлагаемые бесплатно, если эти продукты будут обрабатывать данные [Company], и на продукты, приобретенные с помощью корпоративной карты, личного заявления о расходах, бесплатного пробного периода или оформления самообслуживания у поставщика.
Эта политика не распространяется на набор персонала, объекты инфраструктуры, закупку маркетинговых медиа или юридические услуги, которые регулируются [related policy].
3. Определения
Ежегодные обязательные расходы: общая сумма, подлежащая оплате поставщику за любой период в двенадцать месяцев, включая лицензионные сборы, платежи за место, сборы за использование, сборы за поддержку и затраты на внедрение.
Риск для данных: самая чувствительная категория данных [Company], которую продукт будет хранить, обрабатывать или передавать; оценивается на уровне того, что продукт способен получать, а не того, что запрашивающий намерен в него передать.
Владелец: указанное лицо, ответственное за отношения с поставщиком, его стоимость, решение о продлении и его окончательный вывод из эксплуатации.
Shadow IT: любая технология, которая используется, но не отражена в реестре технологий.
4. Роли и ответственность
Запрашивающий указывает бизнес-потребность, рассматриваемые альтернативы и данные, с которыми будет работать продукт.
Владелец, который может быть запрашивающим, ведет отношения на протяжении всего срока, подтверждает решение о продлении и инициирует вывод из эксплуатации.
ИТ оценивает техническую пригодность, стоимость интеграции, пересечение с инструментами, которые уже есть, и нагрузку по поддержке.
Security оценивает меры контроля поставщика, сертификаты, субпроцессоров и историю инцидентов, а также определяет, требуется ли соглашение об обработке данных.
Finance подтверждает бюджет, фиксирует обязательство и контролирует способ оплаты.
Legal рассматривает условия по ответственности, возмещению убытков, правам на расторжение, формулировкам об автоматическом продлении и юрисдикции.
Владелец политики, [role], поддерживает эту политику и реестр и отчитывается по обоим в [committee] каждый [quarter].
Шаблон политики ИТ-закупок, часть вторая: запрос, проверка и покупка
5. Запрос
Все запросы подаются через [request form or ticket queue] до создания любой тестовой учетной записи, до подписания любого договора и до осуществления любой оплаты. Запросы, поданные после того, как обязательство уже принято, рассматриваются как исключения по пункту 12.
Каждый запрос указывает искомый бизнес-результат, категории данных, с которыми будет работать продукт, ожидаемое количество пользователей за двенадцать месяцев, ежегодные обязательные расходы, срок действия договора и то, может ли какой-либо инструмент, уже принадлежащий [Company], удовлетворить эту потребность.
6. Проверка и согласование
Запросы маршрутизируются с использованием таблицы маршрутизации согласований в [Appendix A]. Согласование фиксируется в [system] у согласующего, с датой и утвержденными ежегодными обязательными расходами. Согласование предоставляется на указанный срок и указанные расходы. Оно не переносится на продление, продление срока или увеличение расходов более чем на [15] процентов.
7. Проверка безопасности и данных
Любой продукт, который будет обрабатывать персональные или регулируемые данные, проверяется Security до согласования. Проверка включает сертификаты безопасности поставщика и их область действия, субпроцессоров и страны, где хранятся данные, механизмы аутентификации и контроля доступа, обязательства по уведомлению об инцидентах, механизмы экспорта и удаления данных, а также любую историю нарушений.
Если обрабатываются персональные данные, соглашение об обработке данных выполняется до того, как продукт получит реальные данные. Если обрабатываются регулируемые данные, [Company] дополнительно [insert the assessment your regulator or framework requires].
8. Договоры и оплата
Подписывать договор или принимать условия предоставления услуг от имени [Company] могут только [named roles]. Принятие соглашения с «кликните, чтобы согласиться» — это подписание договора.
Legal рассматривает все соглашения с ежегодными обязательными расходами выше [15,000] и любые соглашения любой стоимости, которые включают автоматическое продление, обработку персональных данных, эксклюзивность или обязательство по минимальному объему, либо срок дольше двенадцати месяцев.
Оплата производится через [purchase order or corporate card held by Finance]. Личные карты и возмещение расходов не являются одобренным способом оплаты для покупок технологий при любой стоимости. Карты, выданные отдельным лицам, не могут использоваться для регулярных платежей за технологии.
Каждый одобренный продукт фиксируется в реестре технологий до того, как будет выпущена первая оплата.
Шаблон политики ИТ-закупок, часть третья: продление, выход и исключения
9. Продление
Продление — это решение о закупке, а не бухгалтерское событие.
Никакое соглашение не заключается, если уведомление о непродлении требуется более чем за [60] дней до даты продления, за исключением случаев, одобренных по пункту 12.
За [Ninety] дней до каждой даты продления владелец завершает проверку продления, включающую сравнение активных мест с лицензированными местами за предыдущие девяносто дней, фактических расходов с одобренными расходами, был ли достигнут исходный бизнес-результат, покрывает ли теперь какая-либо другая технология, принадлежащая [Company], ту же потребность, и любые изменения в данных, с которыми работает продукт.
Проверка продления утверждается тем же уровнем, который утвердил первоначальную покупку, с использованием текущих расходов и текущего риска для данных. Если любой из этих параметров перевел продукт на более высокий уровень, более высокий уровень утверждает.
Продления, не рассмотренные [30] дней до даты продления, эскалируются на [role]. Если владелец покинул [Company] и преемник не назначен, продление по умолчанию не утверждается, а продукт рассматривается как кандидат на вывод из эксплуатации.
10. Владение и реестр технологий
[Company] ведет реестр технологий, фиксируя для каждого активного продукта: поставщика, продукт, владельца, орган, утвердивший решение, и дату, ежегодные обязательные расходы, дату продления, период уведомления, категории обрабатываемых данных, наличие соглашения об обработке данных, лицензированные места и держателя административной учетной записи.
Реестр проверяется [quarterly]. Любое списание по корпоративной карте или банковской выписке, которое нельзя сопоставить с записью в реестре, расследуется в течение [30] дней.
Когда сотрудник уходит, [role] проверяет реестр по продуктам, которыми он владел, и переassignает владение до его последнего дня. Административный доступ к любой учетной записи поставщика передается на роль-ориентированную учетную запись, а не на конкретного человека.
11. Вывод из эксплуатации
Когда продукт выводится из эксплуатации, владелец экспортирует данные [Company] в пригодном для использования формате, направляет поставщику документально оформленный запрос на удаление и фиксирует ответ, удаляет все учетные записи пользователей, отменяет платежный инструмент или заказ на покупку, обновляет реестр и подтверждает, что ни одна зависимая система больше не вызывает продукт.
Вывод из эксплуатации не считается завершенным, пока не зафиксировано подтверждение удаления.
12. Исключения и экстренные покупки
Экстренная покупка может быть выполнена без полного согласования, если простой сервиса, инцидент безопасности или юридическое обязательство делает задержку недопустимой. [Role] может это разрешить. Полный путь согласования завершается в течение [10] рабочих дней, а покупка фиксируется в журнале исключений.
Все остальные исключения требуют письменного согласования от [role] и фиксируются с указанием причины и даты окончания действия. Исключения не продлеваются.
13. Несоблюдение
Неодобренные покупки технологий не подлежат возмещению, а продукты, которые обрабатывают данные [Company] без одобрения, будут отключены при обнаружении. Повторное несоблюдение рассматривается по [disciplinary policy].
14. Проверка
Эта политика проверяется [annually] [role] или раньше после существенного инцидента, изменения регуляторного обязательства или изменения структуры компании.
Скопируйте сюда.
Разбор на примере и сколько это стоило
Meridian Freight, штат триста десять сотрудников, имела политику закупок с порогом согласования в пять тысяч долларов. Это была разумная политика. Вот как она дала сбой.
В марте 2024 года руководитель команды поддержки купил инструмент аналитики по тикетам: пять мест по восемьдесят девять долларов за место в месяц, четыреста сорок пять долларов в месяц по корпоративной карте. Политика читала транзакцию, а не обязательство, и четыреста сорок пять никогда не приближались к пяти тысячам, поэтому ничего не сработало. Годовое обязательство составляло пять тысяч триста сорок долларов — это было выше порога.
Инструмент загружал полные тела тикетов, а тикеты Meridian содержат имена клиентов, адреса доставки, номера телефонов и детали по отправкам. Проверка безопасности не проводилась, соглашение об обработке данных не было подписано, а список субпроцессоров поставщика так и не был прочитан.
Руководитель ушла в ноябре 2024 года, и ее карту переоформили на преемника в рамках стандартной финансовой передачи, поэтому списание перешло вместе с ней.
Инструмент продлили в марте 2025 года. Цена за место выросла с восьмидесяти девяти до ста девятнадцати долларов, а выставление счетов было основано на использовании, поэтому мест стало одиннадцать — по мере добавления людей в общие очереди. Ежемесячная стоимость выросла примерно до одной тысячи трехсот долларов. Никто это не согласовал, потому что согласовывать было нечего. Это было списание по карте, которое всегда было там.
Аудит по картам в феврале 2026 года это выявил. Из одиннадцати мест три были активны в течение предыдущих девяноста дней. Общая сумма, уплаченная за двадцать четыре месяца, составила около восемнадцати тысяч двухсот долларов, из которых пять тысяч триста сорок — результат решения, которое принял кто-то. Остальные двенадцать тысяч восемьсот пятьдесят два были потрачены никем.
Важной была не сумма денег. Двадцать месяцев персональных данных клиентов находились у неподтвержденного поставщика, и поскольку административная учетная запись принадлежала сотруднику, который ушел, Meridian не могла экспортировать или удалить свои данные без открытия тикета в поддержку и подтверждения владения. На это ушло одиннадцать дней.
Каждый пункт здесь, который выглядит как «накладные расходы», существует из-за какой-то версии этого. Пункт 8 останавливает персональную карту. Пункт 9 делает март 2025 решающим моментом. Пункт 10 ловит несопоставленное списание и переassignает владение при выходе. Пункт 11 означает, что запрос на удаление — это не первый раз, когда кто-то об этом думает.
Написание и запуск за две недели
Первая неделя: установите истину до того, как вы напишете правило. Возьмите двенадцать месяцев данных по картам и банку и перечислите все регулярные платежи за технологии, затем спросите каждого руководителя команды, что из используемого есть у них, но отсутствует в этом списке — именно так обнаруживаются бесплатные инструменты. Назначьте владельца для каждой строки. Все, что никто не забирает, — ваш первый кандидат на вывод из эксплуатации. Этот инвентарь станет первой версией вашего реестра.
Вторая неделя: установите пороги, опираясь на распределение, которое вы только что нашли, а не на круглое число. Адаптируйте пункты выше, попросите Legal и Security проверить пункты 7, 8 и 11 и согласуйте таблицу маршрутизации с теми людьми, которым придется жить по ней. Опубликуйте ее вместе с реестром, а не раньше. Политика без реестра — это документ, политика с реестром — это контроль.
Относитесь к запуску как к изменению поведения, а не как к объявлению. Люди не покупают инструменты вне процесса из-за небрежности — они делают это, потому что процесс медленнее дедлайна. Если ваш путь согласования не может обработать запрос с низким риском за два рабочих дня, вашу политику будут обходить. Установите SLA для согласований и опубликуйте свою производительность относительно него — наш гайд по управлению изменениями раскрывает это подробнее.
Что исключить
Критерии выбора поставщика и матрицы оценки относятся к руководству по поиску (sourcing). Политика, которая описывает, как взвешивать демо поставщиков, устареет в течение года и будет слишком длинной, чтобы ее прочитать до этого.
Список поставщиков должен быть в реестре, потому что указание одобренных поставщиков в политике означает контроль изменений каждый раз, когда вы переключаете инструмент.
Пошаговые инструкции для вашей системы закупок должны быть в IT SOP. Политика говорит, что нужен заказ на покупку, SOP говорит, какая кнопка поднимает уровень, и раздельное хранение этих документов позволяет менять систему без повторного открытия политики.
Документы, которые стоит подготовить вместе с этим: шаблон IT-документации для систем, которые вы в итоге купите, реестр приложений и учетных данных — естественное место для реестра технологий, описанного в пункте 10, SOP по передаче знаний для передачи владения в пункте 10 и шаблон плана ИТ-проекта для всего, что достаточно крупное и требует внедрения.
Заметка о юридической и регуляторной проверке
Этот шаблон — отправная точка, а не юридическая консультация. Обязательства по закупкам существенно различаются в зависимости от юрисдикции и сектора. Организации государственного сектора, регулируемые финансовые учреждения, поставщики медицинских услуг и организации, подпадающие под правила публичных тендеров, несут предусмотренные законом требования, которые этот шаблон не пытается воспроизвести. Пункты об обработке данных по-разному взаимодействуют с GDPR, UK GDPR, CCPA и отраслевыми правилами — в зависимости от того, где находятся ваши субъекты данных и ваши поставщики.
Перед публикацией попросите вашего юриста и руководителя по защите данных или комплаенсу проверить пункты 7, 8 и 11, а также подтвердить ваши пороги относительно любой делегации полномочий, которая уже была одобрена вашим советом.
Как превратить политику в то, что люди действительно выполняют
Политика, которая живет в общей папке, читается один раз. Версия, которой следуют, — это та, которая прикреплена к моменту, когда она нужна, то есть к моменту, когда человек собирается что-то купить.
Trupeer AI превращает запись экрана в документированный процесс, поэтому путь запроса в пункте 5 становится пошаговым обзором вашего реального запроса в форме, а не абзацем, описывающим его. Запишите процесс один раз — и вы получите пошаговое руководство, видео и документ в вашем knowledge base из той же записи, в вашем собственном брендинге.
Запишите. Оформите в бренде. Переведите. Trupeer it.
Для команд, которые поддерживают библиотеку политик, документация и создатель SOP держат политику, реестр и процедуры вместе, а перевод означает, что глобальная команда финансов читает таблицу маршрутизации согласований на своем языке. Инструкции по настройке находятся в гайде по настройке шаблона документа.
Часто задаваемые вопросы
Есть ли версия этого шаблона политики ИТ-закупок для Word?
Полный текст политики находится на этой странице между двумя маркерами «copy», и он написан так, чтобы пережить копирование и вставку. Выберите пункты 1–14, вставьте в Word или Google Docs — и нумерация и жирные заголовки сохранятся. Нет закрытой загрузки Word, которую нужно запрашивать, а значит, нет и формы по email между вами и текстом.
Есть ли версия PDF или PDF по политике ИТ-закупок, который я могу разослать?
Вставьте текст в редактор документов и экспортируйте в PDF оттуда. Это лучше, чем фиксированный PDF для этого документа, потому что политике закупок нужно подставить ваши пороги, названия ролей и валюту в квадратные скобки, прежде чем это что-либо будет значить. PDF, в котором в пункте 2 все еще написано [Company], — это не политика, а рассылка такого документа учит людей, что политика носит декоративный характер.
Могу ли я скачать этот шаблон бесплатно?
Текст бесплатный и без ограничений. Используйте его, редактируйте, публикуйте внутри компании под своим именем. Вам не нужно указывать Trupeer AI в документе политики.
Что такое COBIT APO10 и соответствует ли ему этот шаблон?
APO10 — это цель COBIT, охватывающая управляемых поставщиков: от выбора поставщика до управления отношениями, управления договорами и мониторинга эффективности на протяжении всего жизненного цикла поставщика. Политика закупок — это входные данные для APO10, но не то же самое.
Этот шаблон хорошо покрывает части, связанные с приобретением и заключением договоров, а пункты 9 и 10 — некоторые аспекты текущего управления отношениями. Он не покрывает карточки оценки эффективности поставщиков, мониторинг SLA или распределение рисков поставщиков по портфелю — все это ожидает APO10. Если вы работаете над оценкой COBIT, рассматривайте это как один из нескольких документов, которые вам понадобятся, а не как контроль, закрывающий цель.
Что такое простая политика закупок и когда ее достаточно?
Простая политика закупок обычно занимает две-три страницы: цель, область применения, таблица порогов расходов и кто подписывает. Для компании примерно из пятидесяти человек, которая покупает только стандартные инструменты без регулируемых данных, этого действительно достаточно, и политика из четырнадцати пунктов не будет выполняться.
Если вам нужна короткая версия, оставьте пункты 1, 2, 4, 6, 8 и 9 и уберите остальное. Не убирайте пункт 9. Дисциплина продлений — это единственный контроль, который окупается в любой компании, и это пункт, который чаще всего отсутствует в коротких политиках.
Охватывает ли это SaaS и облачные сервисы или только оборудование?
И то и другое, а область применения в пункте 2 написана так, чтобы это было явно, потому что именно двусмысленность — место, где большинство политик «утекают». Облако и SaaS — более сложный случай, поэтому в таблице маршрутизации есть строка для нулевых расходов и колонка для риска для данных. Покупки оборудования в большинстве компаний маршрутизируются чисто по расходам.
Кто должен владеть этой политикой?
Тот, кто отвечает за расходы на технологии — в большинстве компаний это CIO, IT Director или Head of IT, а в небольших компаниях часто COO или Finance Director. Важнее названия то, что владелец видит данные по карте и банку, описанные в пункте 10. Владелец политики, который не видит начисления, не сможет ее обеспечить.
Как часто нам нужно ее пересматривать?
Ежегодно — разумный вариант по умолчанию в пункте 14. Пересматривайте раньше, если у вас был инцидент безопасности с участием поставщика, если регулятор изменил обязательства, которые применимы к вам, если вы приобрели компанию или сами были приобретены, либо если при ежеквартальной проверке реестра два квартала подряд обнаружились несопоставленные начисления. Последнее — сигнал о том, что таблица маршрутизации или SLA согласований не работает, а не о том, что людям нужно напоминать о политике.
