Проблемы быстродействия систем ERP – системный кризис
Мартынов Дмитрий
www.koderlogic.ru
Описанные в данной публикации индивидуальности рынка ERP не имеют цели запятнать репутацию поставщиков корпоративных решений, а отражают общую тенденцию развития. Непременно, на этом рынке встречаются и исключения, которые упрямо гребут против течения, подтверждая каждый раз свою неплохую репутацию. Но они - в меньшинстве.
Как бывает в жизни? Внедрена ERP-система, началась работа. Традиционно - это высококачественное улучшение информированности менеджмента, увеличение скорости обмена информацией, получение способности контроля операций и многое другое. Ежели все внедрено отлично, а такое бывает, то все скоро привыкают к отличному. Отменная система дает менеджеру несколько выгодных преимуществ. И здесь вдруг…
Представьте, что вы приходите на работу, и вам нужно срочно приготовить отчет к совещанию. Но почему-то у вашего рабочего места нет стула, и взять его негде. И калькулятор сломался. А еще электричество отключили, потому комп не врубается. Уборщица куда-то переложила со стола самые принципиальные папки!!!
Приблизительно такие же чувства испытает менеджер, когда выяснится, что отчетность, которую он получает через ERP, он впору не получит.
Ежели система начинает тормозить, это создает трудности на почти всех рабочих местах. Ежели ввод инфы является должностной обязанностью, то при остановке системы человек попадает в тупиковое положение. Он должен ввести данные об операции в систему, но не может этого сделать. Как позже доказать, что была виновата система?
Когда ситуация повторяется, то несовершенство системы становиться некоторым корпоративным явлением. Менеджмент начинает находить методы подготовки отчетности без ERP.
Возникают новейшие аннотации по вводу данных типа: «Если ввод данных выполнить не удается, попытайтесь выполнить ввод через 10 минут, ежели через 10 минут ситуация повториться, - обратитесь к админу». Возникают новейшие бизнес-процессы, которые все усложняют. В итоге пропадает часть эффективности использования ERP.
Вопросец, «почему?» звучит смешно. Не поразмыслили о будущем, не протестировали… Но неувязка обычная. Почти все интеграторы, внедряющие ERP, частенько делают это без учета возможных заморочек, которые могут наступить при наборе критической массы данных, либо развитии системы.
Обстоятельств несколько:
• Более распространенные ERP технически устарели.
• Интеграторы продают системы не соответствующие бизнес-процессам.
• Интеграторы заинтересованы в дилеммах клиента (звучит грубовато, но это факт).
• У Интегратора нет кадров опытнейших в вопросцах быстродействия.
Все четыре предпосылки, являются системными и вытекают из особенностей бизнеса по внедрению ERP систем, потому остановимся на каждой из их поподробнее.
Почему распространенные 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, но и от её настройки. Означает, включить в контракт настройки/внедрения гарантии от Интегратора по быстродействию может быть, но при определенных усилиях.
Требования по быстродействию должны быть четкими. Следует указать количество юзеров, количество операций в единицу времени. Не забудьте об определенном запасе, на неточность расчета, также на рост вашей компании.
Быстродействие - это вопросец технический, и, как следствие, сильно зависит от кадров. Принципиальная его изюминка заключается в том, что об данной дилемме нужно позаботиться заблаговременно, так как часть источников замедления совсем тяжело ликвидировать, когда система уже работает.
По материалам: http://www.insapov.ru