Переписать ERP- обычное дело. Умеем ли мы считать эффективность? Спецвыпуск «ИТ– сделано в России»

21 октября 2019
2

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

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

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

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

________________________________

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

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

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

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

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

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

О плюсах

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

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

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

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

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

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

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

Что делать?

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

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

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

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

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

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

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

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

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

1696
Поделиться
Коментарии: 2

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Виктор Федько
    Рейтинг: 298
    АО МПО им.И.Румянцева
    Зам. начальника управления информационных технологий
    28.10.2019 13:32

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

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

    Вообще же, кастомизация не сама по себе родилась. Она берет начало из славных 90-х/нулевых, когда 1С еще был 6 и 7 версиями и к ERP отношения не имел. А по ИТ просторам нашим уверенно шагали SAP, OeBS, Infor, IFS и иже с ними. Их везде шикарно продавали, а потом выяснялось, что к российским реалиям они не совсем пригодны в принципе. и что громкое слово "локализация" на этапе пресейла есть не более чем пустой звук. И начиналась допилка, дочистка, рихтовка - сиречь та самая пресловутая кастомизация. вот откуда растут ноги.

    Сейчас, конечно, ситуация выправилась несколько. Уже так просто ERP никому не втюхаешь под обещания все потом доработать. Но даже любимая 1С со всеми своими отраслевыми решениями не является эталоном - все равно какие-то доработки нужны. Нужны, прежде всего, потому, что зачастую бизнес-заказчик еще живет в другом измерении и привык к чему-то другому. прежнему. И диктует условия, соответственно, не понимая, что это все ведет к удорожанию продукта. но и это постепенно уходит в прошлое, а бизнес-заказчики многие на пенсии. А новые. ни к чему не привыкшие, стараются работать в имеющихся шаблонах и рамках. и дорабатывать самый минимум, чисто в форме "бантиков".

    Очень ценное напоминание в статье - "чувствовать разницу между «настройкой» системы и изменением конфигурации." Это точное и очень правильное замечание.

    На общемировой тренд многие российские компании переходят уже. Особенно те, которые принадлежат бусурманам. Там и ERP другие и перечень требований иной, как правило. И менеджмент несколько иного толка подбирается.

    у кастомизации грабли одни , но зато большие и больные - кто потом будет все это поддерживать? Как быть с обновлениями системы от вендора и что потом делать с кастомизацией ? Насколько глубоко надо описывать все сделанные изменения? Насколько грамотно это должно быть реализовано. Уже этого достаточно, чтобы трижды задуматься о кастомизации.

    Тут важно понимать еще одну вещь. И грань. Где кончается кастомизация стандартного функционала ERP и где начинается заказная разработка своей собственной ERP? Надо четко отдавать себе отчет и понимать разницу 9 и видеть ее) - где выгоднее внедрить с модификацией что-то , а где заказать полностью свою разработку под ключ. Или сделать своими силами. Лет 25 назад мы сделать свою систему а-ля ERP на заводе. своими силами. Денег не было на SAP да и смысла тоже. Все тогда было сыро очень. И система работала, развивалась и умерла не так давно. Вместе с заводом и некоторыми разработчиками (((. Но заменить ее никто не рискнул. Смотрели разные спецы из разных ERP-контор. Качали головами и признавались , что повторить не смогут - только сильно кастомизировать свое.
    Так что этот момент тоже надо иметь в виду. Хотя, думаю, все эти проблемы уходят в прошлое постепенно. А где-то быстрее. Будущее за стандартными функциональными модулями, настраиваемыми на все случаи жизни.

  • Александр Власов
    Рейтинг: 14
    Проектные решения
    Руководитель направления
    29.10.2019 10:18

    Да, вопрос кастомизации всегда сложен. Не понятно во что выльется по затратам

Предметная область
Отрасль
Управление