ERP системы: что это простыми словами, плюсы и минусы ERP, обзор. V Внедрение ERP-системы на предприятии. Где взять ERP систему для предприятия

Рынок ERP-систем в России стремительно растет. Однако проекты по внедрению ERP-систем нередко заканчиваются неудачей. По оценкам специалистов, примерно 70% проектов внедрения систем ERP не достигают заявленных целей. Предлагаем обсудить основные причины. Ведь предупрежден, значит, вооружен.

Рынок систем ERP (Enterprise Resource Planning – «планирование ресурсов предприятия») остается одним из самых быстрорастущих рынков программного обеспечения в мире. Объем российского рынка ERP system по итогам 2015 года вырос, по данным TAdviser, на 9%, достигнув 108 млрд (см. рисунок). Выручка 8 из 10 крупнейших игроков отечественного ERP-рынка также показала за отчетный период положительную динамику.

Рисунок

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

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

Скачайте полезные документы :

Ошибка №1. Не описать бизнес-процессы до начала внедрения ERP

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

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

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

Ошибка №2. Постоянно вносить изменения в будущую систему

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

Ошибка №3. Полностью полагаться на автоматизаторов

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

Ошибка №4. Разработать ТЗ на все случаи жизни

Все учесть невозможно, какие-то моменты будут «рождаться» по ходу внедрения и здесь должна быть некоторая степень свободы, в том числе зафиксированная в договоре с внедренцами. Как вариант, можно определить в договоре количество консультационных часов на дополнительные разработки – может входить в стоимость проекта, если реализуется «под ключ», либо рассчитываться дополнительно по ставке человеко-часа. Попытка разработать ТЗ с учетом всех нюансов приведет к созданию огромного талмуда, который вряд ли даже будет прочитан и изучен проектной командой.

Ошибка №5. Не учитывать сопротивление персонала

Если к ERP-проекту не подключать специалистов компании, то риск сопротивления изменениям , внедрению «системы для руководства» может уничтожить все благие начинания. В нашей практике известны случаи, когда под давлением со стороны руководства компания теряла порядка 50% персонала в процессе внедрения системы.

Ошибка №6. Не уделять достаточно внимания проекту внедрения ERP-системы

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

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

Важно понять и принять – внедрение ERP-системы в первую очередь нужно вашей компании. К сожалению, компанию внедренцев это интересует в меньшей степени – их устраивает, что вы регулярно платите по счетам.

Ошибка №7. Пытаться сделать сразу все

По нашему опыту сопровождения проектов внедрения мы убедились, что концепции развертывания проектов на базе scrum (методология гибкой разработки ПО), действительно работают и дают результаты (читайте также про методологию Agile ). Основные принципы, на которые мы делаем акцент – работа в рамках небольших модулей (циклы до 1 месяца) с целью получения рабочей версии продукта на каждом этапе. Далее может идти корректировка и сонастройка остальных модулей с разработанным. Система разворачивается поступательно, гибко подстраиваясь под задачи компании. Пытаясь развернуть систему сразу полностью и потом ее протестировать, вы рискуете потратить весь бюджет и время, а на выходе получить неприятный сюрприз в виде неработающего продукта.

Ошибка №8. Выбрать неподходящую платформу

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

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

Ошибка № 9. Неправильная команда автоматизаторов

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

Ошибка №10. Некорректные цели внедрения ERP-системы

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

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

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

Процесс внедрения ERP-систем условно делится на 7 этапов: организационные работы, обследование предприятия, выбор методологии автоматизации, проектирование системы, развёртывание ПО на рабочих местах сотрудников, запуск системы в промышленную эксплуатацию, сопровождение.

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

I Организационный этап

Работа над проектом внедрения ERP на предприятии начинается с определения цели и задач . Это не должна быть автоматизация ради автоматизации - заказчик должен чётко знать, каких бизнес-эффектов он в итоге желает достичь.

На подготовительном этапе также необходимо сформировать рабочую группу на стороне клиента. В неё должны войти:

Руководитель (желательно из числа топ-менеджеров компании). Этот человек должен хорошо разбираться во всех аспектах деятельности предприятия и организации бизнес-процессов. Кроме того, руководитель проекта внедрения ERP должен иметь возможность принятия единоличных решений по любым возникающим вопросам.
Специалисты , ответственные за соответствие системы требованиям действующего законодательства и корпоративным стандартам. Под эту категорию подпадают: исполнительный директор, главный бухгалтер, начальник IT-службы.
Руководители всех отделов , которым предстоит работать в системе ERP. В их задачи будет входить консультирование внедренцев на этапе изучения бизнес-процессов предприятия и организация работы подразделений по завершении процесса автоматизации.
IT-специалист широкого профиля . Его зоной ответственности будет техническое сопровождение проекта.

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

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

II Этап обследования предприятия

По завершении организационных работ проводится обследование бизнес-процессов предприятия. Данная процедура необходима для точного определения сроков и стоимости внедренческих работ. В зависимости от масштабов проекта и поставленных задач IT-интегратор может предложить клиенту один из 2-х вариантов обследования:

Экспресс-обследование . Проводится в течение 1,5–2 месяцев. По его итогам составляется документ «Предпроектный анализ». В нём отражаются особенности автоматизированного учёта и перечень задач, которые необходимо будет решить в процессе внедрения.
Полное обследование . Проводится в течение 3–5 месяцев. По итогам досконального обследования составляется «Техническое задание», разрабатываются бизнес-процессы автоматизированного учёта и описывается перечень необходимых доработок ПО.

Выбор варианта обследования определяется предпочтительной методикой внедрения ERP.

III Выбор методологии внедрения ERP

Внедрение ERP-решений на платформе «1С:Предприятие» может осуществляться по одному из 4-х сценариев:

Абонентское обслуживание . Компания-интегратор проводит экспресс-обследование предприятия, составляет укрупнённый план внедрения ERP и на основе него определяет максимально возможную стоимость проекта. Эта стоимость прописывается в договоре, там же фиксируется стоимость одного часа работы программиста-внедренца. Общий план работ разбивается по месяцам. Исходя из количества рабочих часов определяется размер ежемесячного бюджета. Фиксированная сумма платежа также вносится в договор.
Поэтапная технология внедрения . Данная методология внедрения ERP подразумевает проведение полного обследования предприятия, определение всех автоматизируемых бизнес-процессов и подготовку ТЗ. В техническом задании отражаются: объёмы доработок типовой конфигурации программы, полный перечень работ с разбивкой на фиксированные этапы, сроки и стоимость реализации каждого этапа внедрения ERP. Главный минус данной технологии - негибкость. Внесение мельчайшей корректировки в проект влечёт за собой изменение ТЗ: пересмотр сроков и стоимости выполнения отдельных этапов работ.
Технология быстрого результата . Алгоритм внедрения ERP примерно тот же, что и при абонентском обслуживании. Так же проводится экспресс-обследование, рассчитывается максимальная стоимость проекта, оценивается час работы программиста. Оплата так же осуществляется раз в месяц, но не по фиксированному тарифу, а по количеству реально затраченных программистами часов. Строго регламентированных планов работ на месяц, неделю здесь нет - список и очерёдность выполнения задач может меняться в зависимости от актуальных потребностей предприятия. Гибкость является безусловным плюсом технологии быстрого результата. Включить в проект дополнительные бизнес-процессы можно на любом этапе и без длительных согласований. Единственным недостатком данной схемы внедрения является размытость сроков реализации проекта.
Разовые вызовы . Установка программы на рабочие места сотрудников и автоматизация бизнес-процессов осуществляются по мере возможностей клиента. Предприятие закупает коробку, а все внедренческие работы проводятся по сценарию разовых вызовов.

IV Проектирование системы ERP

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

V Внедрение ERP-системы на предприятии

Программное обеспечение устанавливается на рабочие места сотрудников. Осуществляется настройка прав доступа и отчётов. Производится загрузка рабочих данных и справочной информации из старой системы, файлов Excel и т. п.

VI Запуск системы в промышленную эксплуатацию

Для начала о самом проекте: внедрение 1С:ERP на промышленном предприятии. Когда мы пришли к клиенту (в 2015г), численность завода составляла 5 тысяч человек. За время проекта завод существенно вырос и нарастил объемы производства, сейчас на нем работает порядка 6,5 тысяч сотрудников. 1С установлена на 1,2 тыс. рабочих мест. Активно работающих пользователей сейчас (июнь 2017г) порядка 350, планируется увеличение до 450ти.

Предприятие входит в военно-промышленный комплекс России, и, следовательно, имеет свою специфику.

До этого проекта я запускала средние предприятия (1000-1500 сотрудников, 50-150 рабочих мест). Делать их мы уже научились, выработав четкую методологию (сейчас у меня с командой среднее время перевода проекта в промышленную эксплуатацию 7-10 месяцев, в зависимости от его сложности.)

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

Итак, по порядку. На завод мы пришли в конце 2015г. Изначально стояла задача запуска регламентированного учета. По ходу функционального моделирования руководство Заказчика (с подачи главного бухгалтера) приняло решение о передачи функции ввода первичных документов «на места». Границы проекта были пересмотрены, включив в себя центральные склады, кладовые, цеховую бухгалтерию, управление договорами и БДДС. Сроки внедрения регламентированного учета были сдвинуты на 2017г, а в течение 2016г автоматизировалась «первичка».

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

Если честно, то я думала, что главной сложностью будет саботаж со стороны пользователей. До внедрения 1С те ничего никуда централизованно не вводили: кто-то работал в Excel, кто-то - в самописных системах. Основой документооборота были «бумажки», которые потом сдавались в АСУП для ввода операторами в бухгалтерскую программу. Здесь проектная команда со стороны Заказчика грамотно подошла к вопросу – был выпущен ряд приказов, подписанных генеральным директором, которые закрыли проблему. Приказы оформлялись не в привычном стиле «на нашем предприятии запускается система…», а были вполне конкретными «с такого-то числа бухгалтерия принимает от складов только документы, выписанные из 1С». Для снятия возможного недопонимания мы сразу включили штриховое кодирование документов и раздали бухгалтерии сканеры (реально были попытки сдать документы, «нарисованные» людьми в Word).

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

Первая (хотя и не основная) проблема была вполне предсказуема – это объемы данных. Однако масштабы ее я изначально недооценила. Для примера – просто загрузка (безо всякой обработки) остатков по «малоценке» занимает около 4х суток. А если по итогам вдруг обнаруживаются расхождения, то еще четверо суток, а потом еще.… То есть этот этап работ надо при планировании очень тщательно прорабатывать вместе с заказчиком, буквально по дням. Например, здесь мы пошли по обычному пути: загрузили только справочники и посадили пользователей бить «первичку», чтобы после окончания загрузки остатков, все провести, проверить и выйти на оперативный учет. В итоге мы физически не успели до конца месяца свести учет и начислить погашение стоимости, и чтобы сдать управленческую отчетность, пришлось руками переносить из старой системы суммы затрат, а потом их корректировать из-за разных методик учета.

Так же многих нужных данных в нормальном виде у заказчика нет, и соответственно просить их подготовить надо сильно заранее: например, список открытых заказов нам начали собирать за три (!!!) месяца. Казалось бы, чего уж проще? Предприятие должно владеть информацией, что кому и когда оно должно произвести и отгрузить. Но, как оказалось, в формализованном виде у них были только номера заказов (требование по организации раздельного учета по Гособоронзаказу), а наименование продукции, количество, сроки и т.д. хранились либо где-то в Excel, либо в бумажных договорах.

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

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

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

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

Отдельно стоит упомянуть организацию информирования пользователей программы. Надо заранее встраивать в конфигурацию модули для вывода обязательных сообщений: обзвонить 350 человек и сказать, что обновилась инструкция или что сегодня будет запускаться расчет себестоимости, нереально. Здесь нам сильно помогла заплатка из БСП (библиотека стандартных подсистем).

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

Как я работала до этого: по каждому процессу определялся его Владелец, который формировал по нему требования, мы разрабатывали схему работы, проходились по ней с ключевыми пользователями, после чего утверждали у владельца. Обычно такая методика хорошо закрывает 80% операций, а оставшиеся 20 «подрихтовываются» на этапе опытно-промышленной эксплуатации. По этому пути мы пошли и здесь. Разница между реальностью и представлениями руководителей отделов проявилась практически сразу же. Но начальники говорили «не может быть!», а подчиненные в силу корпоративной культуры им не возражали. В итоге утвержденная схема работы содержала часть слишком трудоемких операций, много избыточных контролей и не содержала определенного количества того, «чего у них точно не бывает». Все это пришлось переделывать в ходе опытно-промышленной эксплуатации. Уже реализованные и сданные доработки в итоге были кардинально переписаны, а сама ОПЭ потребовала постоянного присутствия программистов.

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

Анализируя, по итогам, проект, я пока не вижу способа особо снизить риск значительного расхождения между описанными процессами и реальностью: чтобы подробно проработать схему с каждым подразделением, а потом еще – с их руководителями, бюджет Функционального моделирования придется увеличивать в 5-7 раз, а заказчикам обычно сложно понять ценность данного этапа и заплатить 25% от стоимости проекта просто за «бумажку». Была мысль о тестовом прогоне системы на нескольких подразделениях, которую я попробовала на другом проекте, но в полной мере она себя не оправдала.

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

Третья проблема проекта вытекает из первых двух: большое количество пользователей (для которых нужно много консультантов) и большое количество проектных решений, которые принимаются прямо на этапе ОПЭ. А так как в ERP одну и ту же задачу можно решить различными способами, то разные консультанты используют разные методы, и в итоге система начинает «расползаться». Никакие «совещания по итогам дня» здесь не помогают, потому что из-за объема разных вопросов консультанты многое к вечеру уже просто забывают.

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

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

(32%). После того, как выбор сделан, популярность систем остается сопоставимой: 21%, 18% и 14% соответственно (имеются ввиду те случаи, когда указанные платформы выбираются для внедрения).

В целом сроки ERP-проектов остаются по-прежнему одной из болезненных проблем для данного рынка: только 36% отметили, что смогли уложиться в заранее отведенные временные рамки, а 62% - существенно вышли за них, и только 3% смогли завершить проекты внедрения раньше намеченного. Больше всего выбивались из графика проекты на базе решений Microsoft Dynamics, в среднем они длились 12,5 месяцев, что 4 месяца (47%) больше, чем было запланировано.

Проекты на базе Oracle в среднем длились 22,5 месяца, перерасход времени здесь составлял 29% против в среднем запланированных 17,5 месяцев. Что касается SAP ERP, то средняя длительность таких внедрений составила 18,5 месяцев с минимальной задержкой на 16% или 2,5 месяца против 16 месяцев, запланированных изначально.

Средняя длительность ERP-проектов: запланированная и реальная

Panorama Consulting, 2014

Основные причины задержек ERP-проектов

№	Причина	2011	2012	2013
1	Был расширен объем проекта	17%	29%	29%
2	Организационные вопросы	14%	20%	29%
3	Проблемы с данными	14%	17%	29%
4	Нереалистичные сроки	8%	11%	25%
5	Ресурсные ограничения	13%	17%	21%
6	Проблемы с обучением	10%	15%	17%
7	Проблемы с функционалом платформ	8%	4%	13%
8	Другие технические вопросы	7%	14%	8%
9	Конфликт приоритетов в рамках проекта	10%	12%	8%

Panorama Consulting, 2014

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

Хорошей новостью стало, пожалуй, только то, что в период с 2012 по 2013 годы аналитики зафиксировали снижение среднего срока окупаемости проектов ERP с 2,4 лет до в среднем 1,7 лет. Тем не менее, количество организаций, которые вообще не смогли окупить свои вложения в автоматизированные системы управления ресурсами предприятия, выросло с 31% до 38%. Наиболее долгий период окупаемости выявлен у решений Microsoft Dynamics (24 месяца), у SAP он составляет 23 месяца, у Oracle - 16 месяцев.

И еще один важный момент: фактический бюджет проектов относительно планируемого по итогам 2013 года опять увеличился. Наиболее дорогим внедрением при этом является внедрение SAP ERP , в среднем бюджет такого проекта составляет $2,55 млн, затем следуют Oracle - $2,25 млн, Microsoft Dynamics - $1,8 млн. От годового оборота предприятий внедрение Tier I систем составляет 2-4%, а вот доля стоимости ERP-проектов на базе Tier II и III может быть существенно выше в обороте компаний, выбравших их для внедрения.

Только 66% компаний смогли добиться хотя бы 50% целей

Что касается ERP-проектов в целом (безотносительно конкретных вендоров), то по итогам 2013 года только 66% компаний смогли добиться хотя бы 50% намеченных целей в рамках внедрений. В 72% случаев проект оказался больше по срокам, чем планировалось ранее при средней длительности 16,3 месяцев. В 54% случаев был зафиксирован перерасход бюджета, средний бюджет проекта составил $2,8 млн.

Средние показатели ERP проектов 2012-2013

Panorama Consalting, 2014

63% признали реализованные ERP-проекты успешными, 21% затруднились оценить эффект от внедрения, 16% признали, что внедрение окончилось неудачей.

Российские реалии

В одном из отчетов The Standish Group указывается удручающая статистика о состоянии дел в программной индустрии на американском рынке:

лишь 32% проектов завершились успешно,
44% испытали различные трудности (превысили бюджет, выпали из сроков и пр.),
24% проектов просто провалились.

На российском рынке ситуация едва ли лучше, отмечают эксперты компании «Первый БИТ ».

Статистикой «успешности» ERP-проектов поделились в компании 1С . По данным исследования 555 выполненных внедрений ERP -решений фирмы «1С» в 2010-2013 годах:

66% проектов уложились в срок или имеют незначительное, до 10% отклонение от срока,
24% проектов отклонились от срока на 11-30% и
только 10% проектов отклонились от срока более, чем на 30%.

Что касается бюджетов проектов, то тут ситуация для заказчиков еще более обнадеживающая:

78% проектов укладываются в бюджет или имеют превышение бюджета не более, чем на 10%,
19% проектов имеют превышение бюджета на 11-30% и
только 3% проектов имеют превышение бюджета более, чем на 30%.

Среди основных причин неудач ERP-проектов российские интеграторы выделяют:

Завышенные ожидания

Большая проблема, когда нет чёткого понимания желаемого результата, чего заказчик хочет добиться, отмечает Ефим Фиш , директор по развитию бизнеса Microsoft Dynamics AX Tops Consulting (Топс Консалтинг) . В этом случае, перефразируя известное изречение, проект нельзя закончить, его можно только прекратить. Зачастую заказчики неправильно оценивают свои желания и требуемые затраты. Обе стороны должны согласовать между собой цели проекта и ключевые моменты в отношении того, что необходимо для успешной реализации проекта.

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

Человеческий фактор, отсутствие поддержки руководства

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

В 1С, например, для соблюдения сроков проекта используют методику под названием «Технология Быстрого Результата» (ТБР). Согласно статистике сроков внедрений ERP-решений фирмы «1С» (1420 проектов за 2010-2013 годы), в среднем, до ввода первой подсистемы в опытную эксплуатацию проходит около 3 мес., а до ввода последней подсистемы в промышленную эксплуатацию от 6 до 10 мес. в зависимости от масштаба проекта. На особо крупных предприятиях внедрение может длиться и 1-2 года.

Как уточнил Алексей Петрушов, одним из основных показателей неэффективности проекта является затяжка сроков. Основной причиной этой проблемы, безусловно, является человеческий фактор, добавил он.

* Оплата после внедрения. Успешного внедрения.

«Мы не ищем "виноватых" (виноваты всегда обе стороны) в неудачных внедрениях, мы берем деньги с заказчика, только когда он удовлетворен результатом» - говорит Сабина Борщевская, eBusinessDrive . Мы выполняем внедрение ERP , практически, за свой счет, и, если результат клиента не устраивает - он просто не платит. На текущий момент подобные условия на российском, и уж тем более мировом, рынке внедрения ERP-систем свежи как воздух в горах Швейцарии. Приходите.

Нехватка или перерасход бюджета

Разброс цен на российской рынке ERP -систем является значительным: это определяется тем, что ERP-система – сложный продукт, на конечный результат проекта влияет множество факторов, начиная от функциональности ERP-системы и заканчивая системой менеджмента в организации заказчика.

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