Переписать ERP- обычное дело. Умеем ли мы считать эффективность?

21 октября 2019

Алена Зюскина, Центр внедрения и поддержки ФТО, директор по сервису.

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

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

А как обстоят дела с внедрением ПО в России?

________________________________

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

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

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

Мы попросили наших клиентов поделиться мнениями и дать ответы на вопрос, почему компаниям во время внедрения ERP-проектов (в первую очередь, 1С систем) все чаще требуется тот или иной нестандартный функционал.

Виталий Чернышов, ИТ-директор «Молвест»: «При общей схожести бизнес-процессов в компаниях одинакового профиля уровни автоматизации у всех разнятся. Причины кроются в ожиданиях от внедряемой системы — автоматизация может быть лоскутной, неполной или на устаревших платформах, а для принятия решений руководству необходимы привычные срезы аналитики».

Александр Пискарев, руководитель отдела ИТ «Молочные продукты Русагро»: «На мой взгляд, причины две: 1. ИТ-компании, разрабатывающие отраслевые решения, далеко не всегда хорошо погружены в реальные проблемы бизнеса (я знаю только одну ИТ-компанию, в которой методолог проработала 15 лет на производстве). 2. Неготовность бизнеса взглянуть на процессы по-новому. Как правило, методологию операционных процессов описывают сотрудники на уровне заместителей начальников отделов или старших специалистов. Они хотят получить максимально комфортный инструмент для автоматизации того, что есть. Оптимизация же часто кроется на стыке подразделений».

О плюсах

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

О минусах

К безусловным минусам кастомной разработки относят ее высокую стоимость. Причем речь идет не столько о высокой стоимости внедрения (это еще полбеды), сколько о стоимости владения такой системой – сложность (и дороговизна) поддержки решения может быть на порядок выше по сравнению с использованием стандартного ПО. Кроме того, возникает необходимость дополнительного обучения пользователей. Во многих случаях эксклюзив может обернуться сложностями (вплоть до полной невозможности) обновления решения на новые релизы вендора. Кроме того, после внедрения «не обкатанной как следует» системы нередко возникают проблемы с ее быстродействием.

Как найти баланс между требованиями бизнес-экспертов (предполагающих выполнение доработок) и желанием сократить стоимость внедрения/поддержки?

Павел Карер, директор департамента ИТ “Лидер-Тим”: «Это всегда компромисс. В реальной жизни, конечно, обойтись без доработок не получится, но должен быть коллегиальный орган в компании с участием представителей бизнес-заказчиков, ИТ и менеджмента компании для принятия решений о кастомизации системы».

Виталий Чернышов, ИТ директор “Молвест”: «Нужно дать пользователям больше знаний о возможностях типовой конфигурации системы. Разбить внедрение на этапы, где последние этапы могут уйти за ненадобностью».

Александр Пискарев, руководитель отдела ИТ “Молочные продукты Русагро”: «Я бы выделил несколько направлений работы. 1. Модульная архитектура. Изменяя один модуль, не трогаем всю систему. Например, дописывая блок логистики, не трогаем производство или регламентированный учет. 2. Обсуждаем, действительно ли нам нужны эти доработки и процессы в таком формате. 3. Соотносим стоимость доработок и обслуживания, с одной стороны, и прирост бизнес-эффективности — с другой. Ключевые заказчики в конкретных подразделениях не мыслят такими категориями, эти вопросы необходимо переносить на уровень выше».

Часто разработка и внедрение уникального ПО сопровождается перерасходом бюджета и срывом сроков проекта. Тестирование и исправление багов оценивается с гораздо меньшей точностью, чем работы по запуску. Мы не будем писать о том, какие мы белые и пушистые и никогда не срывали сроков. Проекты с “поехавшими” сроками есть у любого интегратора. Причины могут быть связаны с чем угодно: от неверного выбора системы и конфликта интересов внутри компании-заказчика, до неграмотной проектной методологии на стороне исполнителя.

Что делать?

Если вы понимаете, что без индивидуальной разработки вам не обойтись, а, кроме того, вы «головой и креслом» отвечаете за результат проекта, стоит подумать о выборе более крупного интегратора.

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

Опытный внедренец сумеет вовремя заметить, что заказчик увлекся и сможет убедить его в том, что, например, считать скобки в степлере администратора с помощью 1С, конечно, можно, но вряд ли это будет экономически целесообразно.

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

Резюмируя вышесказанное, можно выделить правила, которыми нужно руководствоваться при заказе нестандартного ERP-проекта:

Правильно подходите к процессу выбора системы. Помните, что каждая организация уникальна, и ни одно стандартное решение не будет соответствовать 100% ваших требований.
Тщательный выбор наиболее подходящего ПО минимизирует настройку и доработки системы.
Приоритезируйте требования к проекту на глобальном уровне. Руководство компании должно определить, где действительно конкурентное преимущество компании, которое в дальнейшем повысит ее эффективность, а где имеют место быть «хотелки» рядовых пользователей.
Четко следуйте политике, утвержденной спонсором проекта.
Регулярно контролируйте содержание и границы проекта. Изменение бизнес-процессов должно быть обоснованным.
У ERP-проекта не может быть “координатора” на уровне “бумаги носить”. Должен быть зрелый РМ, умеющий работать с требованиями, т.к. цена ошибки крайне высока.
Чувствуйте разницу между «настройкой» системы и изменением конфигурации. В ряде случаев достаточно обойтись настройкой уже разработанного решения под специфику учета в конкретной организации. Это сэкономит ваше время и деньги.

Приглашаем обсудить проблему и дополнить ее реальным опытом внедрения нестандартных проектов.

Справедлива ли наша оценка и есть ли вероятность, что в ближайшем будущем российские компании пойдут в общемировой тренд?
Был ли у вас опыт успешного внедрения стандартного функционала с полным отсутствием доработок?
На какие грабли вы наткнулись из-за кастомизации?
Предпринимались ли усилия по сокращению объема модификаций уже после старта проекта?
Был ли реализован функционал, который потом в реальности не использовался? Насколько сильно это отразилось на бюджете проекта?

Будут уместны любые комментарии и замечания.

Вопросы, касающиеся внедрения и поддержки сложных корпоративных систем, можете задать здесь или отправить на наш e-mail support@fto.com.ru

3104