Технологическая независимость: что можно сделать уже сейчас

Иностранные поставщики программного обеспечения уходят из России. Кажется, что нужно срочно заменять зарубежное ПО на отечественное. Или есть другие варианты? Рассказывает Илья Кулаков, директор департамента автоматизации производства IBS.

От представителя компании-интегратора это может прозвучать странно, но если система работает и полностью устраивает, то не нужно срочно менять ее только потому, что она импортная. Большинство крупных заказчиков по разным причинам годами не обновляли свои ERP-системы. Поводом для «апгрейда» могли стать либо катастрофическая нехватка производительности, либо невозможность запустить систему на новом «железе». Поэтому, узнав об уходе вендора, первым шагом должна быть не замена решения, а организация поддержки существующего — своими силами или с помощью внешнего подрядчика.

Что можно сделать уже сейчас

Если есть возможность организовать полноценную поддержку, если для решения хватает лицензий и серверных мощностей и нет опасений в его принудительном отключении, то самым оптимальным решением будет разработка долгосрочной стратегии замены всех, находящихся в зоне риска продуктов на ближайшие три-пять лет. Иначе в спешке миграции на новую платформу можно потерять гораздо больше, чем получить.

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

Создание временного решения

Ключевым фактором успешности стратегии является признание того, что развертываемое на начальном этапе решение будет именно временным. Любые попытки «впоследствии развить функции до нужного уровня» или «сразу проработать все варианты» скорее всего приведут к негативным результатам.

При выборе временного продукта любого уровня, будь то ERP-, EAM-, WMS-, APS-система, следует ориентироваться на следующие параметры:

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

Всеми остальными параметрами можно пренебречь.

Чем в первую очередь можно и нужно пожертвовать для успеха проекта:

1. Интеграция. Там, где это возможно, интеграция должна идти через файлы обмена. Это могут быть как Excel-, так и XML-файлы, которые копируются вручную. Небольшие объемы данных проще и дешевле вводить вручную, что следует из самой временности решения;
2. Отчетность. Лучше сразу забыть про красивую динамическую отчетность. Если система будет уметь выгружать данные в Excel, то «шапку» и «подвал» документа всегда можно добавить из готового шаблона.
3. Документирование. Самый сложный пункт, особенно для организаций, сильно перегруженных бюрократией. Если решение разрабатывается на год-полтора, то формировать и согласовывать массу проектных документов — верный способ погубить проект. При этом разработка многочисленных проектных решений, инструкций и программ может оказаться работой «в корзину».

По сути, такой проект сводится к разработке решения уровня MVP (минимально жизнеспособный продукт), а самая удобная методология для этого ― Aglie/SCRUM с делением на «спринты», то есть этапы, длительностью не более двух недель. На практике это чаще всего означает наличие первого спринта длительностью до трех недель, пока идет отладка процессов в рабочей группе, и далее три-пять спринтов по неделе.

Например, для одного из заказчиков мы реализовывали похожий проект, задачей которого была поддержка процесса длительностью один год до момента появления полноценной ERP-системы. Непосредственно разработка заняла два месяца и еще месяц ушел на обучение пользователей. Через год система прекратила свое существование, а данные успешно мигрировали в целевую систему.

Возвращаясь к ключевому фактору успеха такого проекта, надо отметить, что решение должно рассматриваться как временное, в том числе и конечными пользователями. Все должны понимать, что, во-первых, это не на всегда, во-вторых, это единственно возможный способ работы и, в-третьих, есть понятный срок, сколько это продлится. За заявленное время нужно успеть подготовить и запустить в рамках отдельного проекта полноценную замену, которая оправдает ожидания пользователей. Это будет уже обычный проект внедрения, возможно совсем на другой платформе.

Развитие через типовое решение

Для успеха этой стратегии необходимо не ошибиться с выбором платформы на начальном этапе, так как в отличие от предыдущего варианта, шансов на ошибку она не оставляет.

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

• распространенность, то есть насколько распространена эта платформа и насколько просто впоследствии будет найти специалистов, которые смогут ее развивать и поддерживать. Особенно важно, насколько та или иная платформа/решение поддерживается независимыми интеграторами, а не только единственным вендором;
• наличие требуемых функций «из коробки». Причем крайне желательно, чтобы этих функций было больше, чем требуется.

Как и в случае с временным решением можно пренебречь такими функциями как:

• Интеграция. Главное, чтобы данными можно было обмениваться. Автоматический обмен через шину можно настроить позже.
• Отчетность. Как правило, все коробочные решения имеют минимальный набор отчетных форм и возможность выгрузки таблиц в формате Excel или XML.

А вот с документированием все не так просто. Метод развертывания такого решения — это проведение GAP-анализа (стратегический анализ, с помощью которого осуществляется поиск шагов для достижения заданной цели) и доработка только критичных функциональных разрывов. Эти доработки должны быть тщательно задокументированы. Кроме того, проекту в обязательном порядке потребуется дорожная карта развития, которая позволит избежать конфликтов на протяжении последующих нескольких лет.

Чем будет отличаться такой проект от любого другого проекта внедрения системы:

1. Основным «объектом воздействия» будет не система, а пользователи. В короткий срок потребуется переобучить всех пользователей работать по-другому. На практике это часто оказывается сложнее, чем переделать интерфейсы системы;
2. Понятие опытной или опытно-промышленной эксплуатации практически отсутствует. После миграции минимально-необходимого объема данных система сразу запускается в промышленную эксплуатацию;
3. Доработка системы будет происходить параллельно с промышленной эксплуатацией. За первый год может выйти три-четыре релиза, дополняющих стандартную функциональность, каждый из которых принесет и набор ошибок, и необходимость дополнительного обучения пользователей.

О способе внедрения уже говорилось — это классический GAP-анализ и постепенное закрытие GAP там, где это необходимо. Далее составление «бэклога» и плана развития. Главное — пройти первый релиз.

Как реализовывать

Для подобных проектов нужны компании со специалистами, имеющими опыт работы как минимум в двух платформах — исходной и целевой. Причем желательно, чтобы эту экспертизу совмещал один специалист, который часто стоит дороже. Кроме того, квалификация таких специалистов должна позволять разбираться в реализации процессов при минимальном объеме консультаций со стороны заказчика и говорить «на одном языке» с конечными пользователями, то есть быть еще и бизнес-аналитиком.

На чем можно сэкономить:

1. Исторические данные и миграция. Необходимо сразу определиться, каким объемом данных можно пожертвовать без ущерба для процесса.
2. Исчерпывающая документация. Чем выше уровень документирования заменяемых систем, тем проще будет настроить процессы «максимально близко». Естественно, документация должна быть актуальной, и большее значение имеет не сколько техническая, сколько процессная составляющая.
3. Готовность к изменениям. Если речь идет именно о «выживании», то надо быть готовым менять бизнес-процессы под требования системы, к их максимальной типизации.
4. Снижение бюрократии в задачах обеспечения доступа, предоставления информации, согласования документов.

Чего точно нельзя делать:

1. Пытаться выполнить такой проект своими силами, не обладая нужным количеством специалистов, потому что в нем обязательно будут проблемы. Реализовывать его должны компании, способные оперативно вывести в проект в три-четыре раза больше людей, когда это потребуется.
2. Совмещать проекты «быстрого замещения» с другими процессами. В отличие от классических внедрений здесь не получится параллельно с внедрением поправить регламенты или осуществить организационные изменения. Все это нужно будет делать потом, когда ключевая задача по переходу будет завершена или войдет в спокойную фазу внедрения.
3. Диктовать свою волю подрядчику. С того момента, как подрядчик выбран и приступил к работам — он становится главным.

Вопрос готовности

У нас часто спрашивают, можно ли за три или шесть месяцев внедрить ERP-систему или ее модуль. Мы всегда делим этот вопрос на две составляющие: можем ли мы, и сможет ли заказчик. Для серьезной консалтинговой компании вопрос развертывания ERP-решения и миграции данных за несколько месяцев — это лишь вопрос возможности мобилизации нужного количества ресурсов. Гораздо больше проблем вызывают получение доступа к ресурсам, готовность инфраструктуры, согласование документов и готовность пользователей. Внедрение ERP обычно занимает от девяти месяцев, но с учетом того, что в рабочем дне — восемь часов, а в сутках — 24, эту задачу можно сократить до одного квартала. Когда просят о замене решения за три календарных месяца, то надо понимать, что это будет 90 рабочих дней. Мы к такому темпу готовы. А готовы ли вы?