Обозрение подготовлено

версия для печати
Как не превратить ERP-систему в черный ящик

Как не превратить ERP-систему в "черный ящик"

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

Впервые о задачах редокументирования программного обеспечения заговорили еще в восьмидесятых годах прошлого столетия - в связи с большим объемом существующего программного обеспечения и необходимости его изменений. По статистике к концу 80-х годов в решении задачи редокументирования было задействовано около 40% программистов, а в 2000 году их доля выросла до 60%.

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

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

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

По оценкам западных аналитиков, менее четверти проектов автоматизации заканчиваются успешно, причем более половины из них завершаются с превышением плановых сроков и бюджетов. Остальные проекты терпят неудачу. Еще в девяностых годах прошлого века компания Standish Group выявила, что среди проектов длительностью более года и стоимостью от 3 млн долл. число успешных не превышает 15%. И хотя с тех пор прошло немало времени, число проектов, не оправдавших ожидания, все еще остается достаточно большим.

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

Стандарты документирования

Такой важный вопрос, как документирование создаваемых информационных систем, стандартизован как на международном, так и на российском уровне. Самой известной является серия стандартов ГОСТ 34, на основании которой формируются требования к системе документирования многих проектов автоматизации, несмотря на то, что эти стандарты консервативны и трудны в применении. Также в России можно встретить стандарты, разработанные еще в 80-е годы, например, стандарт Единой системы программной документации (ЕСПД) – ГОСТ 19, который охватывает часть документации, создаваемой в процессе разработки программных средств. Самым "новым" стандартом в этой области можно считать Международный стандарт ISO/IEC 12207: 1995-08-01 на организацию жизненного цикла продуктов программного обеспечения. Но он ближе к разработчикам и его применение не всегда оправдано в проекте внедрения ERP-системы. В целом, говоря о состоянии стандартизации в этой области, можно констатировать, что большая часть стандартов морально устарела либо не подходит для современных ERP-проектов.

В связи с этим многие вендоры разрабатывают и используют собственные методологии внедрения ERP-систем, создавая таким образом соответствующие методики и технологии документирования этих проектов. Наиболее известными на настоящий момент методологиями являются у SAP - ASAP (Value SAP); у Oracle - AIM (Applications Implementation Method); у Microsoft Dynamics - Sure Step. Особое внимание в перечисленных методологиях уделяется процессам документирования проекта внедрения ERP-системы. Например, в Oracle AIM выделен отдельный процесс DO – документирование системы, а также формализована методология отображения бизнес-процессов (ОВМ) которая позволяет описывать деятельность компании в рамках проекта внедрения системы. В свою очередь, Value SAP является методологией, которая объединяет методы и инструменты этого вендора с инструментом Solution Manager, который включает в себя планы проектов по внедрению различных решений SAP, а также описание существующей функциональности SAP.

Документирование проекта внедрения SAP

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

Как уже отмечено выше, существует множество методологий внедрения ERP, и в большинстве своем они имеют фазы, которые содержат работы по описанию бизнес-процессов "как есть" и формирование процессов "как должно быть" с учетом существующего функционала ERP-системы. При этом число транзакций и функций системы SAP настолько велико, что требует специализированных инструментов для документирования проекта внедрения. В дополнение к вышесказанному, одной из проблем является непонимание между бизнес-заказчиком и ИТ-специалистом, которые очень часто используют различную терминологию. Поэтому для того, чтобы говорить на одном языке, часто используют специализированные методологии описания деятельности (бизнес-процессов, организационной структуры, документов и информационных систем) и соответствующие инструментальные средства, например ARIS Platform. На основании созданного описания бизнес-потребностей и существующих бизнес-процессов формируется концептуальный проект, содержащий модели бизнес-процессов "как должно быть" с учетом существующего функционала ERP-системы и необходимых доработок. Учитывая тот факт, что более 17 тыс. компаний в 120 странах уже выполнили 88 тыс. внедрений SAP, есть смысл рассмотреть примеры, связанные с проектами внедрения именно этой ERP-системы.

Преимущества использования ARIS и SAP Solution Manager

Источник: IDS-Scheer, 2008

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

Редокументирование внедренной ERP-системы

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

В случае редокументирования системы SAP в ней предусмотрен инструмент RBE Plus for SAP Solution Manager, который позволяет собирать статистику по выполняемым за определенный период времени транзакциям. Как только такая информация собрана, становится возможным использование специализированного решения ARIS Re-documentation Solution - для того чтобы определить, какие функции какими транзакциями автоматизированы в существующих бизнес-процессах. Используя полученные модели бизнес-процессов с транзакциями SAP, остается только достроить их в части деятельности, не автоматизированной системой SAP, что позволит получить картину текущей ситуации в виде, удобном  для восприятия как бизнес-пользователям, так и ИТ-специалистами.

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

Практика проектов редокументирования показывает, что использование определенных пользователем транзакций (user-defined) находится в пределах от 10 до 50%, что дает возможность для совершенствования внедренной системы и, следовательно, уменьшение совокупной стоимости владения. При этом в проектах замечен тренд к увеличению числа user defined транзакций в несколько раз, в то же время процент их реального использования уменьшается. Такая же ситуация и со специально разработанными отчетами: число неиспользуемых user defined отчетов составляет порядка 80-85% от общего количества.

На примере одного из проектов можно проследить, в какой степени редокументирование внедренной системы позволяет сократить трудозатраты на ее апгрейд. В рамках одного зарубежного проекта внедрения SAP было создано более 1500 user defined транзакций. При этом редокументирование показало, что только 1200 из них используются. Если учесть, что при апгрейде для настройки одной транзакции нужен один человеко-день, то суммарно трудозатраты на доработку неиспользуемой функциональности составят 1200 человеко-дней, что при ставке 800 евро в день может составить около 1 млн евро. С отчетностью ситуация бывает не лучше. В одном проекте было разработано 8000 user-defined отчетов, при этом 7700 из них не использовалось.

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

Андрей Коптелов

Техноблог | Форумы | ТВ | Архив
Toolbar | КПК-версия | Подписка на новости  | RSS