Реестр исключений первой волны: как учитывать временные отклонения при запуске 1С
При запуске первой волны внедрения 1С редко удается сразу перевести все подразделения и процессы на новый порядок.
Один отдел просит начать на неделю позже. По отдельному виду документов еще не согласован маршрут. У части пользователей не хватает прав или вообще пока не согласован их доступ в 1С. Несколько договоров уже находятся на финальном согласовании по почте, поэтому переносить их в систему в середине процесса нецелесообразно. В 1С:CRM часть клиентов пока не готова к переносу из-за дублей и неполных данных.
Обычно такие ситуации появляются между делом: «этот договор еще закончим по почте», «этот отдел подключим позже», «этих клиентов пока оставим в Excel». Решение кажется понятным, поэтому его не всегда записывают отдельно, но через неделю уже трудно вспомнить, кто разрешил работать по старому порядку, к каким документам относилось исключение и когда оно должно было закончиться.
Поэтому документирование договоренностей - наше всё! На проектах я обычно завожу для таких решений отдельную таблицу — реестр исключений первой волны. В нее попадают случаи, по которым заказчик сознательно решает временно работать не по общему правилу.
Что здесь понимается под первой волной
Под первой волной дальше буду понимать ограниченный запуск нового процесса или крупного изменения.
Например, это может быть запуск 1С:Документооборота для нескольких видов документов, перевод части отдела продаж на 1С:CRM, включение нового маршрута согласования или первый этап обмена между 1С:ДО и учетной системой.
На первой волне не пытаются сразу включить весь контур. Сначала проверяют работу на ограниченной группе пользователей: понятны ли роли, хватает ли прав, правильно ли работают маршруты, готовы ли данные, отчеты и инструкции.
В плане проекта такой запуск обычно выглядит достаточно просто: есть дата старта, перечень подразделений, процессы и ответственные. Но после начала работы появляются пограничные случаи.
Например, новые договоры уже должны согласовываться в 1С:ДО, но несколько документов были созданы до запуска и почти прошли согласование по почте. Или сделки уже нужно вести в 1С:CRM, но по части клиентов еще не завершена проверка данных.
Из-за таких случаев обычно не переносят весь запуск. Их выносят в отдельные строки и разбирают по своим срокам.
Что считать исключением
Исключение — это согласованное временное отклонение от основного порядка первой волны.
Например, общее правило звучит так:
С 1 августа все новые договоры поставки создаются и согласуются в 1С:Документообороте.
При этом отдельно можно согласовать:
Договоры, которые были отправлены на согласование по почте до 1 августа, завершаются по старому порядку до 10 августа.
Такое решение не отменяет запуск 1С:ДО. Оно относится только к конкретной группе документов и действует до установленной даты.
При этом не каждый вопрос первой волны является исключением.
Если у пользователя не открывается файл, это дефект или задача на проверку прав. Если сотрудник не понимает, где завершить задачу, это вопрос поддержки или обучения. Если руководителю понадобился новый отчет, это новое требование.
В реестр попадает только тот случай, когда временно разрешено работать не по основному правилу.
У рабочего исключения всегда есть причина, согласующий, ответственный и дата пересмотра.
Почему недостаточно договориться в переписке
В первые дни запуска у команды одновременно появляется много вопросов. Пользователи уточняют порядок работы, администратор исправляет доступы, аналитик разбирает спорные сценарии, руководители принимают решения по отдельным документам.
Одно исключение согласуют в чате, второе — на созвоне, третье — в письме. Пока случаев немного, кажется, что все участники их помнят.
На практике проблема чаще возникает не в момент согласования исключения, а позже. Решение приняли, запуск продолжился, а к временной договоренности больше не вернулись.
Например, отделу разрешили еще неделю отправлять документы по старому маршруту. Прошла неделя, но дату никто не проверил. Через месяц сотрудники продолжают работать так же, потому что считают этот порядок согласованным.
Реестр позволяет собрать такие решения в одном месте. По нему видно, где процесс уже работает по новому правилу, а где пока действует временное отклонение.
Пример: часть договоров осталась в почте
Компания запускает первую волну 1С:Документооборота. С понедельника все новые договоры поставки должны создаваться и согласовываться в системе.
В первый день выясняется, что один договор уже три недели согласуется по почте и находится на финальной версии. Второй нужно подписать до конца дня, а инициатор еще не прошел обучение. Третий относится к новому виду документов, по которому маршрут в 1С:ДО проверили не полностью.
Если разбирать каждый случай отдельно в переписке, через несколько дней будет непонятно, какие договоры действительно должны находиться в системе, а какие временно продолжают идти по старому порядку.
В реестре можно записать:
EX-004. Договоры, начатые по почте до даты запуска, завершаются по старому порядку до 10 августа. Причина — документы уже находятся на финальном согласовании. Ответственный — руководитель договорного отдела.
На следующем разборе руководителю договорного отдела уже не нужно вспоминать, кому и что разрешили. Открываем строку EX-004 и сразу видим дату — 10 августа.
Если к этому сроку все старые договоры завершены, строку закрываем. Если нет — отдельно смотрим, какие документы остались и почему. Новый договор, который после 10 августа снова отправили по почте, к этому исключению уже не относится.
Какие строки могут оказаться рядом
В одном реестре рядом могут находиться совершенно разные случаи.
Например, отдел продаж начинает работу в 1С:CRM не 1 августа, а 8 августа, потому что обучение перенесли. Несколько договоров остаются в почте до 10 августа, так как они уже находятся на финальном согласовании. По дополнительным соглашениям бухгалтер временно проверяет оплату вручную, потому что этот сценарий еще не включен в обмен.
Встречаются и строки по данным. Формулировки вроде «клиенты не готовы к переносу» здесь недостаточно. Лучше указать конкретно: какие записи остаются в Excel, кто устраняет дубли и после какой даты менеджеры должны продолжить работу только в CRM.
С правами граница проходит достаточно просто. Если пользователю забыли назначить роль, создаем задачу администратору. Если из-за отсутствия доступа временно меняется сам порядок работы — например, действие выполняет другой сотрудник, — это уже можно зафиксировать как исключение.
По интеграциям действует тот же принцип. Ошибка обмена сама по себе относится к дефектам. Но если вместо автоматической операции команда временно согласовала ручную проверку, такая договоренность должна появиться в реестре.
EX-007. До 15 августа статус оплаты по дополнительным соглашениям бухгалтер проверяет вручную. Причина — этот сценарий еще не включен в обмен. Ответственная — Петрова И.В.
После 15 августа эту строку нужно либо закрыть, либо объяснить, почему ручная проверка все еще остается.
Что фиксировать в реестре
Реестр не нужно делать слишком подробным. Чем больше в нем обязательных полей, тем выше вероятность, что команда перестанет поддерживать таблицу в актуальном состоянии.
Для первой волны обычно хватает следующего набора:
| Поле | Что указывать | Пример |
| Номер | Короткий идентификатор строки | EX-001 |
| Процесс | Участок, к которому относится исключение | Согласование договоров |
| Описание | Что временно работает не по основному правилу | Старые договоры завершаются по почте |
| Причина | Почему принято такое решение | Документы находятся на финальном согласовании |
| Кто согласовал | Кто принял решение | Владелец процесса |
| Ответственный | Кто должен закрыть исключение | Руководитель договорного отдела |
| Дата пересмотра | Когда нужно вернуться к строке | 10.08 |
| Статус | Текущее состояние | Открыто |
Если проект крупный, можно добавить подразделение, вид документа, ссылку на задачу и короткий комментарий по закрытию. Но начинать лучше с минимальной таблицы.
Кто принимает решение по исключению
Исключение не должно появляться только потому, что отдельному пользователю удобнее продолжать работать по старому порядку.
Например, сотрудник говорит, что пока будет отправлять договоры по почте. Руководитель отдела не возражает. Аналитик воспринимает разговор как согласованное решение. Если таких случаев станет несколько, фактический запуск начнет заметно отличаться от плана.
Поэтому отклонение от общего порядка должен подтвердить владелец процесса, руководитель проекта, руководитель подразделения со стороны заказчика.
Я обычно использую простое правило: если ситуация меняет порядок работы пользователей, ее нужно согласовать и внести в реестр. Если речь идет об ошибке настройки или разовом вопросе, достаточно обычной задачи поддержки.
Почему важна дата пересмотра
На первой волне часто звучит фраза: «Пока оставим так». Иногда это разумное решение. Но без даты пересмотра временный порядок легко становится постоянным.
Например, подразделению разрешили еще неделю вести часть документов по старой схеме. Если дата нигде не указана, через месяц сотрудники могут продолжать работать так же. Не потому что они отказываются переходить в систему, а потому что никто не вернулся к принятому решению.
Поэтому в реестре лучше фиксировать именно дату пересмотра. В этот день нужно решить, что делать со строкой: закрыть исключение, продлить его с новой причиной или создать отдельную задачу.
Если срок продлевается второй или третий раз, временное решение стоит разобрать отдельно. Скорее всего, причина уже находится не в первой волне, а в процессе, данных, правах, обучении или настройке системы.
Как работать с реестром после запуска
На первой волне обычно достаточно просматривать открытые строки один или два раза в неделю. Большое отдельное совещание для этого не требуется.
На рабочем разборе проверяют, какие исключения еще актуальны, где истек срок, что мешает закрытию и не требуется ли отдельная доработка.
Лучше не делать для такого реестра сложную статусную модель. Обычно хватает четырех состояний: «Открыто», «В работе», «Продлено» и «Закрыто».
Если выяснилось, что без изменения системы исключение не закрыть, его лучше перевести в отдельную задачу. В реестре при этом можно оставить ссылку на нее и срок следующей проверки.
Если строка две недели не меняется, ее стоит отдельно вынести на разбор.
О чем договориться до запуска
До старта первой волны достаточно один раз определить, кто может предложить исключение и кто принимает окончательное решение.
Иначе аналитик может записать строку после разговора с пользователем, руководитель подразделения будет считать ее согласованной, а владелец процесса узнает о новом порядке только на общем разборе.
На той же встрече стоит решить, где хранится реестр, кто следит за датами и как часто открытые строки пересматриваются.
Пользователям не нужно знать все детали работы с таблицей. Но руководители и ключевые участники запуска должны понимать, куда передавать нестандартные случаи и кто может разрешить временное отклонение.
Как понять, что реестр ведется формально
Это становится заметно достаточно быстро. В таблице есть открытые строки, но на рабочих разборах их никто не открывает. По части исключений уже прошла дата пересмотра. Некоторые решения остаются только в чатах, поэтому реестр показывает не всю картину.
Еще один признак — в таблицу начинают добавлять всё подряд: ошибки, запросы на новые отчеты, вопросы пользователей и задачи по правам. Через некоторое время реальных исключений среди этих строк почти не видно.
До запуска достаточно договориться о четырех вещах: кто может предложить исключение, кто его подтверждает, кто отвечает за закрытие и в какой день к строке вернутся.
Дальше работа простая. Один или два раза в неделю открываем просроченные строки и по каждой задаем вопрос: это отклонение еще нужно или уже можно вернуться к обычному порядку?
Если на этот вопрос никто не может ответить, значит, исключение уже осталось без владельца и реестр нужно приводить в порядок.