- PVSM.RU - https://www.pvsm.ru -
Очень часто переход компании на новую ERP-систему останавливает не финансовые затраты на покупку и доработку, а необходимость миграции со старой системы. У них есть сотни или даже тысячи пользователей, которые выполняют свои бизнес-процессы в одной программе, и каким-то образом их нужно всех пересадить в другую без какой-либо остановки для бизнеса.
За последние годы мы прошли этот путь несколько десятков раз, и у нас уже выработался наименее болезненный способ, как это сделать.
День, когда Байсон почтил твою деревню своим присутствием, стал для тебя самым главным в жизни. Но для меня это был вторник.
— Байсон, «Уличный боец»
Процесс перехода часто осложняется тем, что многие особо впечатлительные сотрудники заказчика в первое время находятся в состоянии паники, так как для них это, скорее всего, первая миграция в карьере. Для нас же это рядовое событие, которое, как правило, проходит по одному и тому же сценарию.
Когда любой человек меняет один продукт на другой, то первым делом он замечает то, что у него забрали и пока не осознает того, что получил. Поэтому часто первой реакцией является: “что за ерунду вы мне тут подсунули — сделайте так, как было”. У нас на практике была ситуация, когда один пользователь жаловался, что ему неудобно новое действие, которое в старой системе делалось в пять переходов между формами. Но оно у него было отточено до такого автоматизма, что человеку действительно в первое время было быстрее его сделать, чем делать два новых, но гораздо более простых действия.
Еще одна сложность заключается в том, что при переходе заказчики любят изменять бизнес-процессы под свое видение. К этому нужно относиться с большой осторожностью, так как текущие процессы “as is” гарантированно работают. Процессы, заложенные в продукт, как правило, тоже работают, так как используются у других клиентов. А вот новые изобретения могут в теории выглядеть красиво, но на практике упереться в какую-то мелочь, из-за чего весь процесс может застопориться.
На практике существует два основных сценария по переходу с одной системы на другую:
Определяется дата перехода на новую систему. Разрабатываются все функции по выгрузке данных из старой системы и загрузки их в новую. В день X ночью запускается миграция, и на утро все пользователи со всеми бизнес-процессами начинают работать в новой системе по новому.
На бумаге все красиво. Но на практике возникают как минимум четыре категории проблем:
Когда все эти четыре проблемы возникают в первый день или неделю перехода одновременно, то потерь для бизнеса не избежать. Поэтому такая схема эффективно работает только на небольших проектах. Например, когда количество пользователей меньше сотни и процессы не являются критичными.
Понятно, что можно потратить больше ресурсов на обучение и тестирование системы непосредственно перед переходом, и тогда проблем будет меньше. Но в жизни сотрудники заказчика обычно относятся к этим процессам «спустя рукава» и надеются на «авось». Или просто ошибаются, ожидая, что определенный процесс сможет заработать в определенной постановке, а на самом деле, казалось бы мелкие нюансы, все зарубят на корню.
При таком подходе происходит горизонтальное (по процессам) или вертикальное (по пользователям) разделение системы на части, которые внедряются по очереди друг за другом. Это позволяет разнести все вышеописанные проблемы во времени и решать их по мере поступления меньшим количеством сил.
Дальше я буду описывать процесс миграции ERP-системы [1] на базе открытой и бесплатной платформы lsFusion [2] для розничной сети магазинов, так как мы специализируемся именно на этой индустрии. Но такой же принцип мы применяли и у клиентов из других областей.
Обычно для компаний, которые поддерживают старую систему, является большим ударом новость о замене их программы и потере клиента. Некоторые впадают в неадекватное состояние и начинают угрожать клиенту немедленной остановкой поддержки. Естественно, это никогда не работает, и никак не может отменить принятое решение. Тем не менее, редко получается договориться с теми, кто поддерживает старую систему о том, чтобы они предоставили таблицы, где хранятся все необходимые для перехода данные.
Сперва нужно определить в каких СУБД хранится необходимая информация и как к ней обратиться. За последние несколько лет нам пришлось столкнуться со следующими СУБД, с которыми работали старые системы:
Благодаря таким подходам ни разу не пришлось обратиться к разработчикам старой системы, что значительно сэкономило расходы клиентов, так как обычно они выкатывали просто огромные суммы за сотрудничество.
Все начинается с импорта мастер-данных. В частности, для розничной торговли первыми реализуется импорт справочников групп товаров, товаров, контрагентов и магазинов. При постепенном переходе существует два подхода к импорту мастер-данных:
Есть случаи, когда используют первый подход, но он является слишком трудоемким и сильно подвержен человеческому фактору с вероятностью ошибок. Поэтому мы всегда используем только второй вариант.
В идеале, старая система могла бы накапливать изменения и каким-то образом сообщать, что требуется переимпортировать. Но обычно никто ничего в старой системе менять и дорабатывать не будет. Поэтому единственная рабочая схема, которую мы используем выглядит следующим образом:
Код на платформе для импорта справочника товаров будет выглядеть следующим образом:
importItems 'Импортировать товары' { |
Работать это будет по следующей схеме:
Фактически, это действие на момент запуска полностью синхронизирует старый и новый справочник. Оно не хранит никакой инкрементной информации, поэтому его можно в любой момент времени запускать повторно, даже если предыдущий обмен был завершен с ошибками.
Так как все действия компилируются в SQL запросы без какого-либо итерирования, то выполняется это все достаточно быстро и безопасно. Обычно обмен справочником товаров размером в 100-200 тысяч записей занимал пару минут. При этом, так как PostgreSQL является версионником, то никакой блокировки работы пользователей в это время не происходит.
Таким же образом постоянно синхронизируются прайсы поставщиков, ассортиментные матрицы, графики заказов и прочая необходимая для работы информация. Тут однако может возникать проблема, что доменная логика в старой системе не совпадает с новой доменной логикой. Например, у нас в системе есть история версий матриц и понятие уровней товара внутри матрицы. Если в старой системе текущий ассортимент магазинов хранится в плоском виде как boolean для магазина и товара, то создается одна матрица для каждого магазина ровно с одним уровнем.
Чаще всего мы включаем действие по синхронизации всех справочников со старой системой раз в час, предоставляя при этом пользователю возможность запустить обмен вручную.
В розничной торговле процесс перевода мы обычно делим вертикально по магазинам и одновременно горизонтально от процессов магазина к процессам офиса.
Первым делом выбирается один магазин, на котором будет начат перевод на новую систему. Реализуется импорт текущих остатков и цен магазина из старой системы в виде приходных документов с соответствующими количествами и ценами:
importInventory 'Импортировать остатки' { |
За несколько недель до старта магазина подключается импорт реализации из POS систем. Это нужно для того, чтобы были исторические данные для формирования заказов в первые дни работы.
Очень часто процесс собственного производства переводится немного позже основных процессов. В этом случае, реализуется выгрузка в старую систему документов по перемещению сырья и импорт оттуда готовых изделий.
В день перевода ночью запускается импорт, а затем на магазин отправляются как сотрудники службы поддержки пользователей заказчика, так и нашей первой линии поддержки. Они помогают пользователям начать работу в новой системе, даже не проходя предварительное обучение. При этом обычно некоторое время не закрывается изменение документов в старой системе, так как люди ошибаются, и им нужна возможность исправлять ошибки. Через пару недель идет переимпорт остатков, и тогда уже запрет на изменение в старой системе.
После того, как на первом магазине выявляются и решаются все проблемы, описанные выше, где-то через пару недель переводятся еще 2-3 магазина. Опять итерация выявления и исправления проблем. И дальше очень быстро переводятся все остальные, в зависимости от ресурсов службы поддержки пользователей клиента. Все это время мастер-данные продолжают вводится в старой системе для того, чтобы могли функционировать магазины на старой системе.
Затем, когда все магазины переведены, то либо постепенно, либо все сразу отключаются импорты из старой системы, и пользователи начинают вводить мастер-данные уже в новую систему.
Сводная информация из старой и новой систем получается либо в бухгалтерии, либо в BI-системе, куда выгружают обе системы одновременно. Там же можно получать сводные отчеты за интервал, который включает в себя время работы в старой и новой системах.
Несмотря на кажущуюся сложность перехода с одной системы на другую, пройдя этот путь несколько десятков раз, понимаешь, что при отлаженной схеме все на самом деле не так страшно. Больше проблем возникает с тем, что большинство сотрудников клиента достаточно консервативны и при малейшей возможности требуют сделать “так, как было”. И тут очень важно наличие у заказчика человека с достаточными полномочиями, который сможет сравнить старые и новые процессы, определить какие из них оптимальнее и суметь “переломить” сотрудников. Или дорабатывать процесс по схеме “как было”, если окажется наоборот.
Автор: weissruss
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/326309
Ссылки в тексте:
[1] ERP-системы: https://github.com/lsfusion-solutions/erp
[2] lsFusion: https://lsfusion.org
[3] Источник: https://habr.com/ru/post/462803/?utm_campaign=462803&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.