Перенос заявок из старой системы в новую: что и как не потерять

Перенос заявок из старой системы в новую (Итилиум, Jira, Excel или любую другую) делается в четыре шага: выгрузить данные, сопоставить поля, статусы и людей, загрузить сначала небольшую выборку и сверить её, затем неделю вести работу в обеих системах и только после этого выключить старую. Откат подготавливают до первой загрузки. Ниже разбираю, как я к этому подхожу и где обычно теряются данные.

Что переносить из старой системы заявок

Когда говорят «перенести заявки», обычно имеют в виду таблицу с номерами и заголовками. Для работы этого мало. Я составляю список из шести частей:

• Заявки. Номер из старой системы, заголовок, описание, дата создания, срок, приоритет, статус.
• Клиенты и заявители. Кто обратился, из какой организации.
• Исполнители. Кто ведёт заявку и кто ведёт её сейчас.
• Время и выполненные работы. Кто, сколько и когда работал: от этого зависят счета и отчёты.
• Комментарии и переписка. Без них непонятно, почему заявка закрыта именно так.
• Вложения. Скриншоты, акты, файлы.

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

Как сопоставить поля, статусы и людей

Это главная часть работы, и делается она в таблице, а не в коде. В три столбца: что было в старой системе, что станет в новой, что делать с остальным.

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

Статусы. Наборы статусов почти никогда не совпадают. Например, в старой «В работе», «Приостановлено», «Ждёт клиента», «Закрыта», а в новой другой набор. Сопоставление нужно записать явно и согласовать с тем, кто в этих заявках работает. Незавершённые заявки без исполнителя я не оставляю висеть в «в работе»: их безопаснее поставить на паузу до назначения.

Люди. Клиентов и сотрудников из выгрузки находят по названию и ФИО, а они пишутся по-разному: с кавычками и без, с формой собственности и без, фамилия с инициалами или полностью. Поэтому сопоставление идёт по нормализованному тексту, а не по точному совпадению, и всё нераспознанное я выношу в отдельный список на ручной разбор, чтобы не создавать «двойников».

Выгрузка из Итилиума, Jira и Excel: что учесть

У каждой системы своя выгрузка, и сначала я смотрю, что она реально отдаёт: вложения, комментарии и списания времени могут лежать в отдельных таблицах или не выгружаться вообще. Если выгружать нечем, остаётся запрос к базе или API старой системы.

Если новая система Jira, у неё есть импорт из CSV, и полезно знать его правила. По документации Atlassian:

• рекомендуют около 1 500 задач в одном файле, а большие проекты загружать частями;
• в таблице обязателен столбец с заголовком (Summary), столбцы сопоставляются по шапке;
• вложения подтягиваются по ссылкам из отдельного столбца, ссылки должны быть доступны из облака Jira;
• статус можно сопоставить только с уже существующим в рабочем процессе, новые при импорте не создаются;
• формат даты задают в мастере импорта, он относится и к дате создания, и к дате изменения;
• пользователей определяют по адресу почты или идентификатору аккаунта.

Если новая система своя или собранная на 1С, правила диктует она, но принцип тот же: шапка таблицы, соответствие статусов, правила сопоставления людей, порции загрузки.

Как не потерять историю и даты

Чаще всего ломаются даты. Новая система при загрузке ставит «сейчас» в дату создания, и все заявки за три года оказываются созданными в день переноса. Отчёты за прошлые периоды после этого бесполезны. Я проверяю заранее, можно ли при загрузке задать дату создания, дату закрытия и дату выполнения работы, и тестирую это на нескольких заявках.

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

Третья: время работ. В моём проекте отчёт нарядов из прежней системы не содержал даты интервала, только время. Поэтому пока берётся день наряда, а заказчика я попросил добавить в выгрузку колонку с датой. Эту ситуацию стоит искать до переноса, а не после: если в выгрузке нет даты, спросите, можно ли её добавить.

Проверка на выборке до полной загрузки

Сначала загружаю небольшую выборку: 20-50 заявок, в которую входят открытые и закрытые, с вложениями и без, с разными исполнителями и несколькими клиентами с похожими названиями. Что сверяю:

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

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

Параллельная работа неделю и откат

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

Откат готовлю до первой загрузки. Резервная копия новой системы перед загрузкой, признак загруженной записи (например, пометка источника или внешний номер), по которому всю загрузку можно найти и удалить, и старая система, которую никто не выключает. Если что-то пошло не так, загруженное удаляется по признаку, а работа продолжается там, где шла раньше.

Как я это делаю

В проекте сервис-деска на 1С с ботами в Telegram и MAX версия 0.4.1 принесла перенос данных из системы заявок, в которой команда работала раньше. Выгрузка из Excel превращается в задачи с внешним номером. Клиент находится по названию без кавычек и формы собственности, сотрудник по словам ФИО, задачи «в работе» и «приостановлено» встают на паузу, уведомления при загрузке не уходят. Отдельно загружаются выполненные работы из отчёта нарядов, они ложатся на задачи. Эффект в часах и деньгах я не измерял: команда ещё не работает в системе каждый день.

Мой порядок для любого переноса: список того, что переносим, таблица соответствия, загрузка на выборке, порциями, неделя параллельной работы, откат. Если вам нужен перенос заявок и настройка новой системы под вашу команду, это автоматизация процессов. Похожую логику я описывал для других задач: переезд с одной CRM на другую, связка 1С и Битрикс24 и уход с Битрикс24 на свою систему без остановки.

Сколько стоит перенос заявок

Цена зависит от того, что и сколько переносим, и в каком виде лежат данные. Ориентиры по моему прайсу:

• автоматизация процессов и документов от 60 000 ₽, срок от 2 недель: настройка новой системы заявок и перенос в её составе;
• разработка по часам от 3 000 ₽/час: разовая загрузка из выгрузки в вашу систему;
• технический аудит от 50 000 ₽, срок от 1 недели, если сначала нужно понять, что есть в старой системе;
• поддержка от 20 000 ₽/мес: доработки и сопровождение после запуска.

Точную оценку даю после просмотра выгрузки и списка того, что нужно перенести. Актуальные цены на странице цен.

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

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

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

Что делать, если в выгрузке нет дат или вложений?

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

Как избежать дублей при повторной загрузке?

Сохранять внешний номер заявки отдельным полем и при загрузке искать по нему: если запись есть, обновлять её, а не создавать новую.

Сколько держать старую систему после переноса?

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

Коротко о главном

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

Если вы собираетесь менять систему заявок и боитесь потерять историю, напишите мне в Telegram с кодовым словом «ВЫГРУЗКА»: посмотрю выгрузку и скажу, что переносится сразу, а что потребует доработки.