Заявка на доступ к информационной системе: образец

Кратко

Заявка на доступ к информационной системе — документ, которым сотрудник, подрядчик или новый пользователь просит открыть, расширить или закрыть доступ к конкретной системе: с ролью, сроком и обоснованием. Смысл формы не в бюрократии, а в том, чтобы решение принимал не тот, кто громче попросил, а тот, кому положено согласовывать, и чтобы доступ автоматически заканчивался, когда в нём отпала нужда. Ниже — готовый бланк заявки и правила его заполнения. Как такую заявку правильно оформить и классифицировать в общей очереди — в статье заявка в Service Desk: как оформить и классифицировать.

Актуально на 23 сентября 2026 года.

Готовый образец

ЗАЯВКА НА ДОСТУП К ИНФОРМАЦИОННОЙ СИСТЕМЕ

Заполняется автоматически: номер, дата регистрации, статус.

ПРАВИЛО РАЗДЕЛЕНИЯ РОЛЕЙ. Тот, кто согласовывает (поле 8), не выдаёт доступ сам (поле 10) — это два разных человека. Правило кажется формальностью до первой проверки: без него согласование превращается в самоодобрение.

ТИПОВЫЕ СРОКИ ДЕЙСТВИЯ — ориентир для заполнения поля 7:

Как заполнять

Одна система — одна заявка. Заявка на доступ сразу к трём системам размывает ответственность за согласование: у CRM и у бухгалтерской системы разные владельцы, и объединённая заявка либо ждёт самого медленного, либо согласовывается формально, без реальной проверки каждой части.

Роль, а не «доступ вообще». «Дать доступ в 1С» — запрос, на который нельзя ответить да или нет: 1С у бухгалтера и у кладовщика — разные права. Поле 5 обязано ссылаться на справочник ролей конкретной системы, а не на свободный текст. Общий принцип классификации самих обращений по видам — виды обращений клиентов: как классифицировать.

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

Срок для временных пользователей — обязателен. «Бессрочно» для подрядчика — самая частая причина, по которой уволившийся полгода назад исполнитель всё ещё может войти в систему. Правило простое: если отношения срочные, доступ срочный.

Согласующий определяется системой, а не заявителем. Если заявитель сам выбирает, кому отправить заявку на согласование, рано или поздно она уйдёт тому, кто подпишет не глядя. Соответствие «система → согласующий» задаётся заранее и не редактируется в момент подачи заявки.

Как проверить

Готовую заявку и уже выданный по ней доступ проверяют по одному и тому же списку:

1. У заявки есть согласующий, отличный от того, кто выдал доступ.
2. Поле «Роль» — конкретное значение из справочника, а не «полный доступ» или пустое.
3. Для срочных пользователей заполнено поле 7 с датой, а не словом «бессрочно».
4. По истечении срока в поле 12 стоит реальная дата отзыва, а не пустое значение полгода спустя.
5. Раз в квартал выборочно: пять случайных действующих доступов — у каждого есть заявка с согласованием, которую можно найти по номеру.

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

Частые ошибки

Доступ выдан раньше согласования. «Чтобы не ждать, я уже открыл, а бумагу оформим потом» — типичный способ, которым формальный процесс становится фикцией: бумага «потом» не появляется никогда.

Роль шире, чем нужно, «на всякий случай». Расширенная роль экономит одну будущую заявку и создаёт риск на всё время, пока доступ не пересмотрен. Дешевле подать вторую заявку через месяц, если понадобится.

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

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

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

Частые вопросы

Чем заявка на подключение к системе отличается от заявки на изменение информационной системы?

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

Нужна ли отдельная заявка на предоставление доступа в систему для внешнего подрядчика?

Да, и с обязательным сроком действия, привязанным к договору. Для штатных сотрудников поле 7 можно оставлять «бессрочно с пересмотром», для подрядчика — нет: связь с окончанием договора снимает необходимость отдельно вспоминать об отзыве.

Как оформить заявки на доступ к информационным системам для целой группы сотрудников сразу?

Одна заявка допустима, если у всех в группе одна и та же роль в одной системе и одно основание — например, весь новый отдел получает стандартную роль в CRM по приказу о создании отдела. Если роли различаются хотя бы у одного человека — заявки разделяются.

Кто отвечает, если заявку согласовали, а доступ оказался избыточным?

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

Как это устроено в TehProf.kz Support

Заявку на доступ, оформленную как обращение, TehProf.kz Support ведёт по тем же правилам, что и любую другую заявку: своя категория, приоритет и статус — от «Новой» до «Выполнена», с промежуточным «Ждём клиента», если согласующему нужно уточнение. На канбан-доске такие заявки видно отдельной колонкой по статусу, и не нужно листать общий список, чтобы понять, сколько запросов на доступ ждут согласования прямо сейчас. Если согласующий не отвечает дольше договорённого срока, по заявке можно поставить напоминание с текстом и получателем — уведомление придёт получателю по его собственным настройкам оповещений независимо от того, вспомнит ли о заявке исполнитель сам. Кто внутри компании вправе просматривать и назначать такие заявки, настраивается в разделе ролей и прав — отдельно от того, кто получает доступ к самим системам, о которых идёт речь в заявке.

Связанные статьи

• Приём и обработка заявок от клиентов: как выстроить
• Форма приёма заявки в техподдержку: образец полей
• Как написать ответ клиенту, чтобы не пришлось отвечать второй раз
• Хелпдеск: что это простыми словами
• Роли и права
• Напоминания