Об использовании ERP для автоматизации предприятий в нашей стране начали говорить еще в конце прошлого века. Несомненно, что и содержание, и, главное, практика применения ERP-систем за прошедшие годы существенно изменились. О том, что представляет собой сфера ERP сегодня и каковы перспективы ее развития, обозреватель PC Week/RE Андрей Колесов беседует с заместителем руководителя аналитического центра корпорации «Галактика» Иваном Еремеевым.
PC Week: Развитие спроса — главная движущая сила развития ИТ-рынка. Как изменились потребности заказчиков в сфере ERP за последнее, скажем, десятилетие?
Иван Еремеев: Надо признать, что о комплексной автоматизации на базе ERP-решений в конце 90-х было все же больше разговоров, чем реальных дел. Конечно, шло внедрение ИТ, но все же это была довольно фрагментарная автоматизация. К внедрению собственно ERP-систем приступили в начале нынешнего столетия, но и тут во многом наблюдалось то, что называется “автоматизация ради автоматизации”, т. е. ИТ внедрялись не столько потому, что это реально было необходимо для решения бизнес-задач, а потому, что это “нужно”. В том числе играли свою роль соображения престижа, что часто скрывалось под лозунгом повышения капитализации предприятий (сейчас уже почти всем понятно, что сами по себе ИТ, без получения от них реальных результатов, не дают прироста стоимости компании).
В последние годы ситуация меняется: заказчику требуются ИТ для решения его вполне конкретных деловых задач, для повышения эффективности и развития бизнеса в целом. А это помимо усиления требований к ПО (функционал, масштабируемость, возможности интеграции) означает, что заказчик хочет получить от поставщика не собственно программу, а решение по автоматизации и организации производства — полный комплекс услуг по реализации проекта внедрения ERP-системы, включая организационный консалтинг и обучение персонала. Предприятию нужно не просто автоматизировать существующие бизнес-процессы, а улучшить их, повысить их эффективность за счет новых возможностей ИТ и внедрения современных методов управления и организации производства. А для ПО становятся особо важными его возможности в плане сокращения сроков внедрения, упрощения эксплуатации и обновления системы.
PC Week: Но ведь сегодня и сами ERP-системы не те, что 10—15 лет назад. Как они изменились с тех пор?
И. Е.: Разумеется, изменились подходы к реализации программных комплексов. Давайте вспомним: в конце 90-х концепция ERP во многом была построена как некоторое комплексное решение “все в одном”, покрывающее все задачи автоматизации деятельности предприятия. Второй важный лозунг тех времен — борьба с ИТ-зоопарками, которые рассматривались как откровенное зло, тяжелое наследие прошлого, от которого нужно было скорее избавляться. Отметим, что в тот момент такой подход был в значительной степени оправдан, поскольку весь мир переживал переход от сложившейся еще в 80-е инфраструктуры мэйнфеймов на клиент-серверную x86-архитектуру. Для нашей страны этот подход был особенно привлекательным, поскольку у нас автоматизация во многом шла с “чистого листа”, без излишнего груза унаследованных ИТ.
Но довольно скоро стало понятно, что вариант «все в одном» уже не годится для рынка. ПО получалось слишком громоздким, плохо управляемым. Каждый конкретный заказчик использовал только нужную ему часть функционала и не хотел устанавливать ненужные средства (и тем более платить за них). ERP-системы пошли по естественному пути реализации модульной структуры. Во многих из них оставлялся только базовый учетный функционал, а целый ряд других возможностей был выделен в самостоятельные направления — CRM, управление цепочками поставок, бизнес-аналитика, управление кадрами и пр.
Радикально поменялось отношение к проблеме «зоопарка». Разумеется, компании должны постоянно вести работу по обновлению ИТ-систем, по их замене на новые варианты, решать вопросы унификации и пр. Но все равно от использования унаследованных приложений, да и вообще гетерогенных сред в самом широком понимании этого термина, никуда не уйти. И это даже нужно рассматривать не как некоторое неизбежное зло, а наоборот — как подход к более эффективному использованию имеющихся ресурсов, возможности применения «лучших в своем классе» решений и т. д.
Таким образом, ERP-системы сегодня должны строиться не только по модульному принципу, но представлять собой интеграционную платформу, на которой строятся и развиваются корпоративные информационные системы.
PC Week: Сейчас общепринятой является практика проведения заказчиком конкурсов с целью выбора решения и исполнителя проектов. Какие тут требования можно выделить в качестве основных?
И. Е.: Я бы тут отметил два момента. Первое — это наличие у поставщика готового решения задачи заказчика с минимальным уровнем доработок (а лучше вообще без них). Второе — наличие реального опыта решения подобных задач с демонстрацией уже выполненных проектов для похожих по профилю организаций. Точно так же никому не нужны долгие проекты по внедрению: никто годы на проект тратить не собирается, максимум сегодня — месяцы. В этой ситуации даже вопрос стоимости — хотя он, конечно, тоже важен — уходит на второй план.
Для поставщика ERP-продуктов это означает, что если он хочет выйти на новый для себя отраслевой сегмент рынка, то сначала должен сделать некоторые долгосрочные инвестиции, реализовав ряд проектов, которые, возможно, не принесут прибыль, отработать на них методику внедрения для данной отрасли или даже создать специализированное решение, а уже потом начать получать доходы в ходе тиражирования приобретенного опыта.
PC Week: Но какими бы готовыми ни были ERP-решения, они ведь все равно нуждаются в настройке и какой-то доводке под требования конкретного заказчика.
И. Е.: Конечно! И потому вопрос кастомизации по-прежнему остается одним из ключевых для ERP-продуктов. Но тут есть одна проблема, которая как раз особенно рельефно проявляется для ERP по сравнению с другими прикладными системами. Речь идет о том, чтобы продукт удовлетворял двум противоречивым требованиям: с одной стороны, имел возможность настройки, с другой — обеспечивал бы защиту ядра от возможного внедрения в него. Собственно, проблема на поверхности выглядит так: надо обеспечить жизненный цикл приложения, в ходе которого идут постоянные обновления версий, а в какой-то момент и достаточно радикальная смена версии системы. И все это нужно делать так, чтобы настройки пользователя не мешали процессу обновления и при этом сохранялись бы при переходе от версии к версии.
Всё должно быть обеспечено на уровне архитектуры системы, имеющей слоистую структуру с разными возможностями корректировки кода пользователями. В частности, пользовательские настройки должны быть четко отделены от ядра, к которому может иметь доступ только вендор.
PC Week: Возвращаясь к вопросу о модульной структуре ERP-решения. Лет пять назад активно обсуждались возможности использования модели SOA, но она явно не прижилась в мире прикладных корпоративных систем, в том числе и ERP. Как вы думаете, почему так получилось?
И. Е.: Наверное, идея дробления системы на достаточно низкоуровневые компоненты оказалась весьма сложной в реализации, к тому же SOA является довольно ресурсоемкой архитектурой. Но понятие модуля тоже весьма значительно изменилось за последние годы. Для заказчика сегодня понятие «модуль» больше ассоциируется не с тем, что, скажем, взяли блок «бухгалтерия», к нему подключили блок «склад» и т. д., а с вопросами оплаты лицензий на функциональность. С точки же зрения архитектуры системы обычно выделяется уровень базовых компонентов и уровень прикладной конфигурации, в которую входит весь функционал данного решения.
PC Week: Но ведь идея SOA заключается еще и в том, что именно некоторая универсальная интеграционная платформа должна стать основой корпоративных систем, в которой ERP будет выступать лишь одним из компонентов. Что можно сказать по поводу такого подхода?
И. Е.: Идея полного отделения инфраструктурного уровня, в данном случае интеграционного, от предметного функционала выглядит привлекательно и даже вроде бы очень правильно, но на практике она не очень хорошо реализуема. Опыт показывает, что базовый прикладной функционал должен находиться на одном уровне со средствами интеграции или даже ниже них.
PC Week: Есть еще один важный компонент корпоративных систем — то, что мы называем системами электронного документооборота. Что можно сказать об интеграции ERP с СЭД?
И. Е.: Я уже много лет работаю в сфере автоматизации предприятий и могу сказать, что почти все разработчики ERP-решений обдумывают возможность реализации функциональности средств документооборота внутри своих систем. Но опять же опыт показывает, что СЭД остается отдельным, достаточно самостоятельным направлением автоматизации. Задачи же интеграции ERP и СЭД встречаются в проектах регулярно и в целом успешно решаются.
PC Week Review: ERP-системы, июнь 2011 (№16)
Автор: Андрей Колесов
«Заказчикам нужны не программы, а решения»
Об использовании ERP для автоматизации предприятий в нашей стране начали говорить еще в конце прошлого века. Несомненно, что и содержание, и, главное, практика применения ERP-систем за прошедшие годы существенно изменились. О том, что представляет собой сфера ERP сегодня и каковы перспективы ее развития, обозреватель PC Week/RE Андрей Колесов беседует с заместителем руководителя аналитического центра корпорации «Галактика» Иваном Еремеевым.
PC Week: Развитие спроса — главная движущая сила развития ИТ-рынка. Как изменились потребности заказчиков в сфере ERP за последнее, скажем, десятилетие?
Иван Еремеев: Надо признать, что о комплексной автоматизации на базе ERP-решений в конце 90-х было все же больше разговоров, чем реальных дел. Конечно, шло внедрение ИТ, но все же это была довольно фрагментарная автоматизация. К внедрению собственно ERP-систем приступили в начале нынешнего столетия, но и тут во многом наблюдалось то, что называется “автоматизация ради автоматизации”, т. е. ИТ внедрялись не столько потому, что это реально было необходимо для решения бизнес-задач, а потому, что это “нужно”. В том числе играли свою роль соображения престижа, что часто скрывалось под лозунгом повышения капитализации предприятий (сейчас уже почти всем понятно, что сами по себе ИТ, без получения от них реальных результатов, не дают прироста стоимости компании).
В последние годы ситуация меняется: заказчику требуются ИТ для решения его вполне конкретных деловых задач, для повышения эффективности и развития бизнеса в целом. А это помимо усиления требований к ПО (функционал, масштабируемость, возможности интеграции) означает, что заказчик хочет получить от поставщика не собственно программу, а решение по автоматизации и организации производства — полный комплекс услуг по реализации проекта внедрения ERP-системы, включая организационный консалтинг и обучение персонала. Предприятию нужно не просто автоматизировать существующие бизнес-процессы, а улучшить их, повысить их эффективность за счет новых возможностей ИТ и внедрения современных методов управления и организации производства. А для ПО становятся особо важными его возможности в плане сокращения сроков внедрения, упрощения эксплуатации и обновления системы.
PC Week: Но ведь сегодня и сами ERP-системы не те, что 10—15 лет назад. Как они изменились с тех пор?
И. Е.: Разумеется, изменились подходы к реализации программных комплексов. Давайте вспомним: в конце 90-х концепция ERP во многом была построена как некоторое комплексное решение “все в одном”, покрывающее все задачи автоматизации деятельности предприятия. Второй важный лозунг тех времен — борьба с ИТ-зоопарками, которые рассматривались как откровенное зло, тяжелое наследие прошлого, от которого нужно было скорее избавляться. Отметим, что в тот момент такой подход был в значительной степени оправдан, поскольку весь мир переживал переход от сложившейся еще в 80-е инфраструктуры мэйнфеймов на клиент-серверную x86-архитектуру. Для нашей страны этот подход был особенно привлекательным, поскольку у нас автоматизация во многом шла с “чистого листа”, без излишнего груза унаследованных ИТ.
Но довольно скоро стало понятно, что вариант «все в одном» уже не годится для рынка. ПО получалось слишком громоздким, плохо управляемым. Каждый конкретный заказчик использовал только нужную ему часть функционала и не хотел устанавливать ненужные средства (и тем более платить за них). ERP-системы пошли по естественному пути реализации модульной структуры. Во многих из них оставлялся только базовый учетный функционал, а целый ряд других возможностей был выделен в самостоятельные направления — CRM, управление цепочками поставок, бизнес-аналитика, управление кадрами и пр.
Радикально поменялось отношение к проблеме «зоопарка». Разумеется, компании должны постоянно вести работу по обновлению ИТ-систем, по их замене на новые варианты, решать вопросы унификации и пр. Но все равно от использования унаследованных приложений, да и вообще гетерогенных сред в самом широком понимании этого термина, никуда не уйти. И это даже нужно рассматривать не как некоторое неизбежное зло, а наоборот — как подход к более эффективному использованию имеющихся ресурсов, возможности применения «лучших в своем классе» решений и т. д.
Таким образом, ERP-системы сегодня должны строиться не только по модульному принципу, но представлять собой интеграционную платформу, на которой строятся и развиваются корпоративные информационные системы.
PC Week: Сейчас общепринятой является практика проведения заказчиком конкурсов с целью выбора решения и исполнителя проектов. Какие тут требования можно выделить в качестве основных?
И. Е.: Я бы тут отметил два момента. Первое — это наличие у поставщика готового решения задачи заказчика с минимальным уровнем доработок (а лучше вообще без них). Второе — наличие реального опыта решения подобных задач с демонстрацией уже выполненных проектов для похожих по профилю организаций. Точно так же никому не нужны долгие проекты по внедрению: никто годы на проект тратить не собирается, максимум сегодня — месяцы. В этой ситуации даже вопрос стоимости — хотя он, конечно, тоже важен — уходит на второй план.
Для поставщика ERP-продуктов это означает, что если он хочет выйти на новый для себя отраслевой сегмент рынка, то сначала должен сделать некоторые долгосрочные инвестиции, реализовав ряд проектов, которые, возможно, не принесут прибыль, отработать на них методику внедрения для данной отрасли или даже создать специализированное решение, а уже потом начать получать доходы в ходе тиражирования приобретенного опыта.
PC Week: Но какими бы готовыми ни были ERP-решения, они ведь все равно нуждаются в настройке и какой-то доводке под требования конкретного заказчика.
И. Е.: Конечно! И потому вопрос кастомизации по-прежнему остается одним из ключевых для ERP-продуктов. Но тут есть одна проблема, которая как раз особенно рельефно проявляется для ERP по сравнению с другими прикладными системами. Речь идет о том, чтобы продукт удовлетворял двум противоречивым требованиям: с одной стороны, имел возможность настройки, с другой — обеспечивал бы защиту ядра от возможного внедрения в него. Собственно, проблема на поверхности выглядит так: надо обеспечить жизненный цикл приложения, в ходе которого идут постоянные обновления версий, а в какой-то момент и достаточно радикальная смена версии системы. И все это нужно делать так, чтобы настройки пользователя не мешали процессу обновления и при этом сохранялись бы при переходе от версии к версии.
Всё должно быть обеспечено на уровне архитектуры системы, имеющей слоистую структуру с разными возможностями корректировки кода пользователями. В частности, пользовательские настройки должны быть четко отделены от ядра, к которому может иметь доступ только вендор.
PC Week: Возвращаясь к вопросу о модульной структуре ERP-решения. Лет пять назад активно обсуждались возможности использования модели SOA, но она явно не прижилась в мире прикладных корпоративных систем, в том числе и ERP. Как вы думаете, почему так получилось?
И. Е.: Наверное, идея дробления системы на достаточно низкоуровневые компоненты оказалась весьма сложной в реализации, к тому же SOA является довольно ресурсоемкой архитектурой. Но понятие модуля тоже весьма значительно изменилось за последние годы. Для заказчика сегодня понятие «модуль» больше ассоциируется не с тем, что, скажем, взяли блок «бухгалтерия», к нему подключили блок «склад» и т. д., а с вопросами оплаты лицензий на функциональность. С точки же зрения архитектуры системы обычно выделяется уровень базовых компонентов и уровень прикладной конфигурации, в которую входит весь функционал данного решения.
PC Week: Но ведь идея SOA заключается еще и в том, что именно некоторая универсальная интеграционная платформа должна стать основой корпоративных систем, в которой ERP будет выступать лишь одним из компонентов. Что можно сказать по поводу такого подхода?
И. Е.: Идея полного отделения инфраструктурного уровня, в данном случае интеграционного, от предметного функционала выглядит привлекательно и даже вроде бы очень правильно, но на практике она не очень хорошо реализуема. Опыт показывает, что базовый прикладной функционал должен находиться на одном уровне со средствами интеграции или даже ниже них.
PC Week: Есть еще один важный компонент корпоративных систем — то, что мы называем системами электронного документооборота. Что можно сказать об интеграции ERP с СЭД?
И. Е.: Я уже много лет работаю в сфере автоматизации предприятий и могу сказать, что почти все разработчики ERP-решений обдумывают возможность реализации функциональности средств документооборота внутри своих систем. Но опять же опыт показывает, что СЭД остается отдельным, достаточно самостоятельным направлением автоматизации. Задачи же интеграции ERP и СЭД встречаются в проектах регулярно и в целом успешно решаются.
PC Week Review: ERP-системы, июнь 2011 (№16)
Автор: Андрей Колесов