Проблемы быстродействия систем ERP – системный кризис

Что ограничивает быстродействие ERP систем, I часть
Что ограничивает быстродействие ERP систем, II часть
Что ограничивает быстродействие ERP систем, III часть

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

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

Примерно такие же ощущения испытает менеджер, когда выяснится, что отчетность, которую он получает через ERP, он вовремя не получит.

Если система начинает тормозить, это создает проблемы на многих рабочих местах. Если ввод информации является должностной обязанностью, то при остановке системы человек попадает в тупиковое положение. Он обязан ввести данные об операции в систему, но не может этого сделать. Как потом доказать, что была виновата система?

Когда ситуация повторяется, то несовершенство системы становиться неким корпоративным явлением. Менеджмент начинает искать способы подготовки отчетности без ERP.

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

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

Причин несколько:

• Наиболее распространенные ERP технически устарели.

• Интеграторы продают системы не соответствующие бизнес-процессам.

• Интеграторы заинтересованы в проблемах клиента (звучит грубовато, но это факт).

• У Интегратора нет кадров опытных в вопросах быстродействия.

Все четыре причины, являются системными и вытекают из особенностей бизнеса по внедрению ERP систем, поэтому остановимся на каждой из них поподробнее.

[Перепечатка материалов ERPnews.ru разрешается только с предварительного согласования с редакцией или автором. Если вы читаете этот материал на другом ресурсе, пожалуйста, сообщите нам об этом editor@12news.ru]

Почему распространенные ERP устаревают технически?

Любая ERP система состоит из программы (бизнес-логики) и данных (информации). Программа состоит из ядра и настраиваемой, модифицируемой при внедрении, части. Ядро – это главная часть системы. Благодаря хорошему ядру ERP-система однажды стала популярной. В дальнейшем ядро обновляли: добавляли новые функции, исправляли баги и др.

Для хранения информации обычно используется СУБД, например Microsoft SQL, Oracle Database и др. Современные СУБД имеют множество новых инструментов, которые повышают возможности и скорость управления информацией. Но ядро ERP их не использует. Оно устарело и не учитывает эти возможности.

Почему же создатели ERP не перепишут ядро системы?

Некоторые переписывают, но те, кто пошли по этому пути, часто теряли свой рынок по нескольким причинам:

• Переписать ядро – процесс дорогостоящий;

• При переходе на новую версию придется переучиваться всей армии специалистов, и нет гарантии, что они станут переучиваться на новую версию системы, а не на систему конкурента;

• Переписать ядро – это сложный процесс. Нет гарантии, что новое ядро окажется удобнее и лучше старого с точки зрения бизнес-логики;

• Для Клиентов переход со старой версии системы на новую будет обозначать внедрение системы заново, а это процесс дорогой и непредсказуемый…

Те, кто не переписал ядро, на данный момент остались в плюсе. Но в такой ERP многие возможности СУБД не используются и скорость обработки данных низкая.

Почему Интеграторы продают неправильные системы?

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

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

Если добавить сюда общеизвестную оторванность маркетинга от реальности, то бестолковое позиционирование систем для малого и среднего бизнеса перестает быть удивительным.

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

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

Кстати, цена продукта для малого и среднего бизнеса вовсе не определяется себестоимостью, а определяется именно маркетинговым позиционированием: с малого бизнеса больше определенной суммы не возьмешь…

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

Разве Интегратор заинтересован в проблемах клиента?

Если система тормозит, значит, это кому-нибудь нужно. Я слышал шутку о пользе проблем у клиента много раз и долго не верил, что это правда. Недавно в очередной раз услышал циничную речь незнакомого прежде менеджера по продажам: «А что плохого, если будут проблемы – нас же пригласят их решить…». Разработчики интеграторов, поддержанные менеджерами, не заботятся о быстродействии. Но бывает и хуже.

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

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

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

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

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

Вот и получается – хуже делаешь – больше платят.

Неужели у Интеграторов нет опытных кадров?

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

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

Причин несколько:

1. Эти спецы не умеют внедрять, а только умеют рулить уже внедренной системой, а внедрять – это особое искусство;

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

3. Они не умеют правильно преподнести себя клиенту (все анекдоты по программистов это как раз про них), они не носят галстуков, не приходят вовремя и т.д. …;

4. Они не привычны к схеме оплаты работ у консультанта, где есть небольшой оклад, а все остальное рассчитывается из часов работы выполненных у клиента.

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

Что же делать?

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

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

Для начала позаботимся о том, чтобы юридически застраховать себя от проблем быстродействия. Ограничения скорости зависят не только от ERP, но и от ее настройки. Значит, включить в договор настройки/внедрения гарантии от Интегратора по быстродействию возможно, но при определенных усилиях.

Требования по быстродействию должны быть четкими. Следует указать количество пользователей, количество операций в единицу времени. Не забудьте об определенном запасе, на неточность расчета, а также на рост вашей фирмы.

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

Подробнее об этом читайте в статье: «Причины замедления ERP».


Мартынов Дмитрий
koderlogic.ru

 

© Галактика, 2007
© Издание 12NEWS (ИП Маринин А.Л.), 2007