Rambler's Top100
 
Статьи ИКС № 12 2010
Дмитрий Борисович МАРТЫНОВ  08 декабря 2010

Системы ERP: заменять, модернизировать или?..

Что делать компании, если действующая система управления ресурсами перестала удовлетворять потребностям бизнеса? Заменить отдельные компоненты или систему целиком? А может, «уйти в облака»?

История вопроса

 

Первые системы управления ресурсами предприятия (Enterprise Resource Planning, ERP) появились в 90-х годах XX века, когда они применялись для планирования потребностей в материалах (MRP) и в автоматизированных системах управления производством (АСУП). С тех пор набор функций систем ERP значительно расширился и охватил все аспекты деятельности предприятия. Основная цель, которую преследуют эти системы, – дать головному офису возможность эффективно управлять всеми подразделениями.

 

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

 

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

 

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

 

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

 

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

 

Недаром, по оценкам аналитической компании Panorama Group, 21% компаний получил только половину ожидаемых преимуществ от внедрения системы ERP, и лишь 13% клиентов были полностью удовлетворены его результатами. Нет ничего удивительного, что многие компании сохранили свои старые системы ERP, зачастую сильно адаптированные, которые исправно служили им на протяжении долгих лет, и ничего не модернизировали.

 

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

 

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

 

Полная замена ERP

 

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

 

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

 

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

 

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

 

Расширение возможностей

 

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

 

Однако вплоть до сегодняшнего дня многие разработчики программного обеспечения не очень помогали клиентам модернизировать системы ERP и их компоненты. Эту ситуацию можно сравнить с покупкой новой кухни. Вместо того чтобы заменить старые приборы и шкафы, типичный поставщик ПО говорит: «Давайте-ка лучше снесем ваш дом, поставим новую кухню, а затем построим дом заново! Мы не знаем точно, сколько времени это займет, но, наверное, несколько месяцев». А заказчикам было бы желательно поставить новую кухню рядом с домом, чтобы экспериментировать с ней до тех пор, пока она их полностью не устроит, а затем договориться о конкретной дате и за одну ночь установить новую кухню вместо старой.

 

Переход от прикладных архитектур к сервисным (SOA) делает такой путь возможным.

 

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

 

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

 

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

 

На площадке или по требованию

 

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

 

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

 

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

 

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

 

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

 

Поэтому модель SaaS лучше всего подходит для стратегического расширения (а не замены) существующих систем ERP, установленных на площадке заказчика.

 

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

 

Следует обязательно договориться о конкретном уровне обслуживания (SLA) в дополнение к требованию общей доступности системы. Сегодня в состав SLA часто включают гарантии производительности системы, безопасности, принадлежности данных и времени устранения неполадок. Рекомендуется даже настоять на гарантиях возврата денег, привязанных к SLA.

 

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

 

 

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!
Поделиться: