Читай: ушла из России/ перестала продавать лицензии/ оказывать поддержку и вообще ведет себя подозрительно.
Первое, что приходит в голову любому руководителю — страшащее слово миграция. Расскажем пошагово, как переехать за 2-3 месяца.
На самом деле если разбить монструозную задачу по переезду на маленькие и понятные, то вы можете увидеть, что все не так уж плохо, и ваши сотрудники и клиенты не будут страдать годами, пока усатый сисадмин перенесет все ваши с трудом накопленные данные на флешке с одного сервера на другой.
1. Миграция данных
Первое и самое важное — это данные. Особенно когда речь касается клиентов и высокого уровня сервиса. Перенос данных дело кропотливое и его сроки зависят от того, насколько раньше они были структурированы. Конечно если до сегодняшнего дня все ваши менеджеры по продажам записывали информацию о клиентах каждый в свою Excel-таблицу, а сегодня вам нужно срочно переехать в новую CRM, то перенос данных может занять пару недель (хотя ELMA365 умеет и с Excel справляться, главное привести их к одному формату).
А вот если у вас уже была система с базой данных и структурированными табличками, то ситуация заметно упрощается, и на перенос одного справочника уходит от 2 до 8 часов. Сюда входят работы по созданию приложения (справочника) в ELMA365, добавлению нужных атрибутов и импорт данных в автоматическом режиме через сгенерированное API. Кстати с документами и их версиями все тоже аналогично.
2. Перенос процессов
И вот когда все данные уже в безопасности лежат в новой системе, пришла пора приступить к творческому процессу — переносу процессов.
Почему процесс творческий? Не только потому что проектирование процесса в Low-code конструкторе отдаленно напоминает рисование. Но и потому, что это возможность покопаться в старых процессах, найти в них узкие места и рудименты и без сожаления с ними распрощаться, оставив в новой системе только самое эффективное и необходимое.
Тем более, что спроектированные процессы можно сразу же запустить и проверить, так ли они отрабатывают, не дожидаясь пока разработчик напишет тонну кода.
По нашему опыту на проектирования стандартного процесса уходит порядка 8 часов. А это значит, что уже через пару дней, вы сможете смело отправлять обращения от ваших клиентов по привычному маршруту, но уже в новой системе.
3. Миграция пользователей
Через месяц ваши сотрудники постепенно начнут мигрировать в новую систему. И, конечно, они ждут, что к этому моменту для них уже будет подготовлена авторизация (желательно, сквозная) и настроены все права доступа, чтобы они видели ровно то, что хотят видеть.
Для этого есть 3 ключевых момента:
- Нарисовать оргструктуру. В типовой (даже в Enterprise-компании) это несложно, так как обычно есть четкая иерархия и административное подчинение.
- Завести в новой системе пользователей и группы для этих пользователей либо же импортировать их с помощью готового сервиса из AD.
- Настроить права доступа для каждой роли/группы. Причем в ELMA365 эта настройка обладает высокой гибкостью, поэтому можно выдавать права не только на разделы и объекты какому-то отделу, но и варьировать права на редактирования/запуск процессов и т. д на уровне конкретных экземпляров приложения. Если это, конечно, необходимо.
Кстати, после прохождения этих трех шагов (в типичном проекте они занимают примерно 2 месяца) чаще всего уже можно запускать пилотные процессы. Но для полного переезда важно навести элементарный порядок и красоту.
4. Проектирование интерфейсов
До этого момента ваши сотрудники могли немного горевать, что раньше по кнопке из другой системы данные «вжух» и оказывались на нужном месте. А тут так не работает! Но пришла пора поставить на место и эту последнюю детальку пазла «Переезд»! Иными словами — необходимо реализовать интеграцию со всеми другими системами, где работают ваши сотрудники (если, конечно, эти другие системы вы не планируете тоже заменить).
Рецепт интеграции прост: берем описание методов, потом описание структур данных, одного разработчика и две системы. Дальше происходит магия выстраивания взаимопонимания между мастер-системой и системой падаваном. Еще пара недель на тестирование. И вуаля! Готово!
Все равно звучит страшновато? А что, если мы скажем, что некоторые системы, например, ELMA365, генерируют API методы, с помощью которых можно добавлять обновлять и удалять данные автоматически при создании нового приложения? Стало легче добавлять, правда? Вот мы и закончили переезд!
Сравнение функционала
В полной версии статьи на нашем сайте мы сделали сравнение функциональности платформы ELMA365 Service, ее российских аналогов и зарубежных вендоров, которые покинули рынок.
Переходите и сравнивайте!
Ближайший вебинар:
Отличная статья, прекрасный язык изложения, прочиталось на одном дыхании! Чувствуется продуманный концепт переноса верхнеуровнево. Интересует несколько деталей: как я понимаю речь идет о плавном переезде без остановки бизнеса заказчика? Если да, то мы обязаны понимать, что просто взять разом и все перенести не получится. Соответственно мы переносим часть критически - важного функционала в плане данных объектов и строим по объектной модели бизнес-процессы в рамках уже новой системы, но вот пока мы строим эти БП, люди продолжают работать в старой системе. Данные добавляются, копятся, возможно правится объектная модель (по запросам юзеров или старым тикетам), и вот нам уже снова нужно делать перенос данных. Возможно ли как-то избежать двойного(тройного и т.д.) переброса данных? Как осуществить наиболее плавный переезд максимально незаметно для заказчика? Какая система будет "дергать" API первой и в рамках какой будет прописываться маппинг объектов?
Спасибо!
По поводу плавности переезда - в целом последовательность шагов будет одинаковая для любой скорости, в зависимости от того на сколько быстро на переехать будут появляться нюансы. Например если систему отключают прямо завтра, то миграция данных пройдет безболезненно - за ночь все перенесли, а вот с интерфейсами явно возникнет беда, и долго придется работать с чем то собранным на коленке.
Если говорить о плавном переезде в разрезе переноса данных есть несколько вариантов.
1. Выбрать точку отсчета - все что до посчитать историческими данными и перенести их как есть (если объектная модель это предусматривает)
2. Реализовать интеграцию со старой системой и на этапе раннего старта с определенной переодичностью данные в новую систему выгружать (т.е мастер система старая)
Здесь мы при хорошем раскладе уже получим насыщенный данными препрод , где можно в том числе тестирование проводить
3. В момент перерезания красной ленточки - запуска в прод данные в новой системе будут уже актуальными и интеграцию можно будет отключить. В целом между шагом 2 и 3 можно увеличивать переодичность обновлений.