Развиваются методологии или развивается рынок?

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

Внедрение "классическое" и "быстрое"

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

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

Классификация методик внедрения ERP-системы

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

Вице-президент по консалтингу Columbus IT Partner Эдуард Зейбель в свою очередь утверждает, что ключевое различие между двумя подходами заключается в том, что "быстрый" способ предполагает внедрение системы в ее "стандартном" исполнении, и соответственно имеет место скорее настройка бизнеса под систему, а не наоборот. Если подобный подход оказывается возможен, то сроки ввода программного обеспечения в эксплуатацию, безусловно, оказываются короче.

Специалисты по системам и специалисты по управлению

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

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

Важность обладания подобными знаниями со стороны заказчика так или иначе признается большинством консультантов. Однако, сегодня уже не всегда необходимо обучение, связанное с процессом внедрения системы. Так, по словам директора по консалтингу группы компаний "Борлас" Виктора Горбунова, в проектные группы в настоящее время выделяются лучшие специалисты из среднего и высшего управленческого звена, обладающие высоким уровнем знаний в области управления. "Сегодня на промышленных предприятиях, где мы ведем проекты, многие участники группы внедрения имеют степени MBA и большой опыт работы на управленческих должностях. Этих людей не нужно обучать базовым управленческим технологиям", - утверждает он.

В основе интеграции - знание бизнеса

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

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

Начало эксплуатации - ключевой этап

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

Впрочем, данный пример - далеко не единственный на российском рынке. Поэтому логично сделать вывод о том, что начало опытно-промышленной эксплуатации является точкой максимума в отношении творческого расширения традиционных методологических приемов ведения проекта. Но при этом, отнюдь не всегда такие расширения - самостоятельно разработанные, "вольные" приемы. Иллюстрацией тому служит все тот же проект на ПНТЗ, а также, внедрение SAP R/3 в LatTelecom. В обоих случаях, для расширения традиционных организационных мер, положенных при запуска системы в опытно-промышленную эксплуатацию, были развернуты системы типа HelpDesk, получившие в последние 1,5 - 2 года широкое распространение на российском рынке в качестве эффективного инструмента обеспечения управления ИТ-инфраструктурой и отдельными информационными сервисами. В проектах на ПНТЗ и в LatTelecom HelpDesk был использован как средство поддержки пользователей системы корпоративного управления. Более того, в LatTelecom пошли еще дальше, организовав эту поддержку в соответствии с соглашениями о качестве сервиса (Service Level Agreement - SLA).

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

В основе правильного внедрения умение измерять

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

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

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

Как известно, аудит, тесно сопряжен и еще c одной важной проблемой сегодняшнего дня - возможностью всесторонней количественной оценки эффективности работы системы, проводимой с целью оперативной корректировки работ по внедрению или методов ее использования. Как правило, под этим понимается возможность в строгих количественных показателях (которые еще надо разработать для конкретного случая) отслеживать такие параметры, как, например, сокращение времени исполнения заказа, сокращение запасов, повышение эффективности использования оборудования и т. д. Об этом говорят и сами консультанты. "Без всякого сомнения, на фазе определения проекта должна быть разработана система KPI, базирующаяся на стратегии компании и целях проекта, при использовании такого подхода эффект от внедрения будет гораздо выше, чем в результате "слепого" внедрения", - утверждает Михаил Сидоренко. В Columbus IT Partner отмечают, что при реализации конкретных проектов мониторинг по ключевым показателям реально используется, если не всегда, то по крайней мере нередко. Отметим также, что сама технология KPI , как известно, становится уже практически стандартом, если говорить о методах оперативного управления бизнесом вообще.

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

От отдельных проектов к управлению портфелем

Ну, и последнее - вопросы изменения традиционных методик вследствие взаимосвязи нескольких проектов на предприятии. Дело в том, что информационная среда, в которую и встраивается любая ERP-система по мере развития рынка, так или иначе становится разнообразнее. Это, в свою очередь, должно поднять интерес к методикам, позволяющим оптимизировать всю "многопродуктовую" информационную среду, в которой функции, выполняемые отдельными подсистемами, тесно взаимосвязаны. Соответственно, на передовые позиции начинают выдвигаться методики под общим названием управление портфелем информационных систем (application portfolio management - APM). Такие решения существуют, к примеру, у META Group или IBM Global Services, применение их на российском рынке, думается, дело ближайшего будущего. На Западе же, судя по публикациям, они используются уже достаточно широко. По определению управление портфелем приложений представляет собой совокупность процедур оценки работы всего спектра корпоративных приложений на соответствие бизнес-целям компании, и выработки четко структурированного по приоритетам плана мероприятий по трансформации ИТ-инфраструктуры.

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