Из всех потоков работ на ERP-программах, которыми я руководил, миграцию данных недооценивают стабильнее всего. Вендор закладывает на данные три месяца. По факту выходит от шести до девяти. К моменту переключения (cutover) половина команды тушит пожары из-за дубликатов, а руководящий комитет спрашивает, почему никто не сказал об этом раньше.
Я создал этот калькулятор, чтобы такой разговор состоялся на несколько месяцев раньше. Он оценивает работу по объектам данных, по объёмам и по целевой ERP-системе и выдаёт оценку в человеко-днях, диапазон стоимости и рекомендуемый подход к миграции. Он не привязан к вендору и работает для SAP S/4HANA, SAP ECC, Oracle Fusion Cloud, Oracle E-Business Suite, Microsoft Dynamics 365 и AX.
На выходе диапазон, а не одна цифра, потому что реальность тоже диапазон. Больше всего на итоговую цифру влияют качество данных, число систем-источников и объём истории, который вы решите перенести.
Выберите целевую ERP-систему. Добавьте объекты данных, входящие в объём работ, и ожидаемые объёмы записей по каждому. Честно задайте флаг качества данных. Калькулятор покажет трудозатраты по объектам, общий диапазон в человеко-днях, диапазон стоимости и рекомендуемый подход (Migration Cockpit, LSMW, индивидуальный ETL или гибридный).
Всё работает в вашем браузере. Ничего никуда не отправляется. Ничего не сохраняется. Меняйте исходные данные сколько нужно, чтобы проверить результат на устойчивость к вашим допущениям.
- Основные данные клиентов: связи «заказчик», «грузополучатель», «плательщик», «получатель счёта», функции партнёров
- Основные данные поставщиков: карточки поставщиков, условия платежа, налог, удерживаемый у источника, банковские реквизиты
- Основные данные материалов: базовые данные, представления завода, представления продаж, MRP, бухгалтерский учёт и калькуляция себестоимости
- Счета Главной книги и план счетов: первичные и вторичные затраты, иерархии
- Места возникновения затрат, центры прибыли, внутренние заказы: основные данные контроллинга
- Открытые заказы на закупку: заголовок, позиции, графики поставки, назначения счетов
- Открытые заказы на продажу: заголовок, позиции, условия, данные партнёров
- Открытые счета (AP и AR): открытые позиции с назначениями и правилами клиринга
- Остатки запасов: по складским местам, партиям, особым запасам
- Исторические финансовые операции: проводки, остатки, перенос остатков на новый год
- Основные средства и история амортизации: по классам основных средств и областям оценки
- Основные данные HR: сотрудники, организационные единицы, должности, если в объём входят SuccessFactors или HCM
Укажите параметры миграции
Поля, отмеченные *, обязательны для заполнения.
Схема всегда одна и та же. Обследование проходит на воркшопах, в присутствии владельцев систем. Они говорят, что данные «в целом чистые». На этом утверждении строится оценка. Никто не запускает ни одного профилирующего запроса, прежде чем цифра попадает в бизнес-кейс.
Один производственный клиент уверял меня, что номера деталей у них стандартизированы. Мы выгрузили данные и нашли 12 разных форматов, которые реально используются. На другой программе основным местом хранения заметок по клиентам оказалось пользовательское поле, которое никто не документировал, и три года истории пропали, потому что маппинг его не учёл. В одной финансовой миграции единственный человек, понимавший старый план счетов, ушёл на пенсию пятью годами раньше.
Дорого обходится момент, когда такие проблемы находят на репетиции переключения, а не при планировании. Исправление качества данных, найденное на второй неделе обследования, стоит нескольких дней. То же исправление, найденное на третьем пробном переключении, стоит программе недель, а иногда и квартала. К этому времени даты уже объявлены, сеть агентов изменений мобилизована, а перенос go-live превращается в разговор на уровне совета директоров.
Правильное решение: профилировать данные до подписания оценки. Запустите реальные запросы к источнику. Посчитайте дубликаты. Посчитайте пустые значения. Посчитайте записи, которые уже сегодня не проходят правила обязательных полей целевой системы. Калькулятор исходит из того, что вы это сделаете. Диапазон стоимости резко расширяется, когда вы честно задаёте флаг качества данных.
Выбор подхода зависит от целевой ERP-системы, объёмов данных и числа систем-источников, которые нужно объединить. Ниже в общих чертах то, чем я пользуюсь, с трудозатратами относительно самого простого варианта.
| Подход | Лучше всего подходит для | Коэффициент трудозатрат | Инструменты |
|---|---|---|---|
| SAP Migration Cockpit (LTMC / LTMOM) | Greenfield S/4HANA, стандартные объекты, средние объёмы | 1,0× | LTMC, LTMOM, шаблоны от SAP |
| LSMW | ECC, миграции из устаревших систем, программы на старых релизах | 1,2× | LSMW, записанные сеансы BDC |
| Индивидуальный ETL через SAP BTP / Integration Suite | Большие объёмы, сложные преобразования, объединение нескольких источников | 2,0× | BTP, CPI, SAP Data Services, Syniti, SNP |
| Гибридный (Cockpit + ETL) | Конверсия Brownfield S/4HANA и выборочная миграция | 1,5× | Cockpit для основных данных, ETL для истории транзакций |
| Нативные средства Oracle | Целевые системы Oracle Fusion Cloud и EBS | 1,3× | FBDI, ADFdi, Oracle GoldenGate |
| Dynamics Data Management Framework | Целевые системы Dynamics 365 F&O и AX | 1,3× | сущности DMF, Azure Data Factory |
Индивидуальный ETL самый гибкий и самый дорогой. Честный тест на то, нужен ли он вам: нарушают ли исходные данные стандартные правила целевой системы так, что ни один шаблон не исправит это без логики для каждой записи. Если ответ «нет», оставайтесь со штатными инструментами.
- SAP S/4HANA (greenfield, brownfield, выборочная миграция)
- SAP ECC (остаётся актуальной для параллельных ландшафтов и поздних миграций)
- Oracle Fusion Cloud ERP
- Oracle E-Business Suite (R12)
- Microsoft Dynamics 365 Finance and Operations
- Microsoft Dynamics AX (2009, 2012)
- Руководители программ, которые оценивают поток работ по данным до того, как системный интегратор назовёт цифру.
- Руководители миграции данных, которые проверяют свою внутреннюю оценку по независимой базовой цифре.
- CIO и CFO, которые проверяют на здравый смысл строку по данным в бюджете внедрения на много миллионов долларов.
- Независимые консультанты, которым нужны обоснованные цифры в предложениях и в проверках программ.
- Внутренние ERP-команды, которые готовят бизнес-кейс, не оплачивая отдельный проект по определению объёма.
- Обоснованная цифра, быстро. Оценка в человеко-днях по каждому объекту вместо одной догадки.
- Нейтральность к вендору. Основан на закономерностях программ SAP, Oracle и Microsoft, а не на методичке одного вендора.
- Рекомендация по подходу. Подсказывает, с чего лучше начать: с Migration Cockpit, LSMW, индивидуального ETL или гибридного варианта.
- Учёт объёма и качества. Диапазон стоимости расширяется при падении качества данных, как это бывает на реальных программах.
- Бесплатно, только в браузере, без регистрации. Ничего не покидает ваш компьютер. Обновляйте страницу и начинайте заново сколько угодно.
Насколько точны оценки миграции данных в этом калькуляторе?
Цифры отражают закономерности, которые я видел на программах SAP, Oracle и Dynamics за последние 25 лет. Они нужны, чтобы задать точку отсчёта для разговора о планировании, а не чтобы заменить профилирование ваших реальных данных.
Сильнее всего на точность влияет то, запускали ли вы профилирующие запросы к источнику. Диапазон стоимости, построенный на честном флаге качества данных, выдерживает проверку. Диапазон, построенный на оптимизме с воркшопов, не выдерживает. Используйте результат калькулятора как базовую цифру в разговоре с интегратором. Если его оценка заметно ниже, спросите, какое допущение о качестве данных он делает и как его проверил.
Переносить исторические финансовые операции или только открытые позиции?
На большинстве программ правильный ответ: открытые позиции плюс начальные остатки, а историю оставить доступной для чтения в старой системе через архив только для чтения или слой отчётности. Перенос всей истории транзакций кратно увеличивает трудозатраты, замедляет сверку и редко окупается.
Исключение: регулируемые отрасли, где по закону история должна храниться в основной системе учёта, и компании, которым скользящее сравнение показателей год к году в новой системе действительно нужно в работе. В обоих случаях коэффициент трудозатрат для исторических данных в калькуляторе учитывает более тяжёлый объём работ.
Какой подход к миграции рекомендует калькулятор?
Он выбирает отправную точку по целевой ERP-системе, набору объектов и объёмам. Greenfield S/4HANA со стандартными объектами обычно приводит к Migration Cockpit. Конверсии Brownfield и выборочные миграции склоняются к гибридному варианту. Большие объёмы, несколько систем-источников или сложные преобразования сдвигают рекомендацию к индивидуальному ETL на BTP или к аналогичной платформе на стороне Oracle или Microsoft.
Рекомендация лишь отправная точка. Настоящее решение принимается после пилота (proof of concept) на выборке ваших данных, а не по калькулятору. Относитесь к результату как к рабочей гипотезе, с которой вы идёте в этот пилот.
Можно ли экспортировать план или поделиться им с командой?
Калькулятор целиком работает в браузере. Результат можно сохранить скриншотом или скопировать цифры по объектам в собственную таблицу планирования. Здесь нет учётной записи, нет экспорта в PDF, и на сервере ничего не хранится. Так сделано намеренно. Если хотите подробнее разобрать цифры, запишитесь на 30-минутный звонок и приходите со скриншотом.
Охватывает ли калькулятор остальные данные, например настройки и безопасность?
Нет. Калькулятор оценивает только основные и транзакционные данные. Данные конфигурации, роли безопасности, индивидуальные разработки и объекты интеграции относятся к другим потокам работ со своими драйверами трудозатрат, и их не стоит сваливать в строку по данным. Сведение всего в одну цифру входит в число причин, по которым оценки миграции данных раздуваются уже на этапе планирования.
Как он учитывает развёртывание в нескольких регионах и юридических лицах?
Калькулятор оценивает одно событие миграции. Для развёртывания по нескольким регионам запустите его по разу на каждую волну и сложите волны, применив понижающий коэффициент для шаблонов, маппингов и инструментов, которые вы используете повторно, начиная с первой волны. По моему опыту, вторая волна стоит примерно от 60 до 70 процентов от первой, третья опускается до 50 процентов и дальше стабилизируется. Локальные объекты данных, связанные с законодательством (налоги, расчёт зарплаты, банки), обычно хуже всего поддаются повторному использованию.
Подходит ли калькулятор для конверсии ECC в S/4HANA по сценарию Brownfield?
Да, и он учитывает меньшие трудозатраты на объекты, которые конвертируются на месте, по сравнению с теми, которым нужен новый маппинг. Конверсия Brownfield обычно составляет от 40 до 60 процентов трудозатрат на данные по сравнению с эквивалентной миграцией Greenfield, потому что структуры клиентов, поставщиков, материалов и плана счетов переходят без повторной выгрузки. Тяжелее обычно конверсия бизнес-партнёров и влияние новой Главной книги на исторические проводки.
Калькулятор бесплатный?
Да. Без регистрации, без запроса почты, без оплаты. Расчёт идёт в вашем браузере, ничего не сохраняется и никуда не отправляется. Если после получения цифры вам нужна помощь с обоснованием миграции данных, запишитесь на 30-минутный звонок.