Intelligent Enterprise: Каковы, по вашему мнению, ключевые акценты, на которых необходимо сосредоточить свое внимание заказчику перед стартом информационного проекта?
Ирина Пирогова: Безусловно, необходимо
обеспечить методологическую поддержку проекта. Под этим понимается целый ряд
мероприятий, о важности которых сейчас уже, наверное, излишне упоминать. Я имею
в виду наличие методологии внедрения как таковой, а также проработанной заранее
организационной структуры проекта. Важно также определить, насколько объект
(или объекты, если таковых несколько) готов к внедрению информационной системы.
И наконец, еще одно условие - определение проектных рисков и путей их минимизации.
Начну с методологической поддержки. Сразу подчеркиваю, что заказчику необходимо самому активно работать в этом направлении, а не только ожидать, что поставщик системы или консультант привнесет методологическую основу проекта. Накапливая опыт автоматизации бизнеса, мы постепенно создавали собственную методологию внедрения. Мы не претендуем на то, что в ней содержатся какие-то принципиальные моменты, которые могли бы совершить качественный прорыв в сфере управления информационными проектами. Наоборот, тезисы методологии, наверное, универсальны для большинства подобных методологий, используемых как поставщиками, так и другими заказчиками. Но все же это наш инструмент, он проходил апробацию и совершенствовался на ИТ-проектах, успешно реализованных в нашей компании.
Согласно этой методологии проектный совет работает как постоянный орган, существующий постольку, поскольку на предприятиях нашего холдинга постоянно идут различные ИТ-проекты. Административный совет, напротив, создается под каждый конкретный проект. У нас предусмотрены роли административных менеджеров проекта, представляющих как исполнителя проекта, так и заказчика, то есть нас. Есть группа внедрения, в которую также с обеих сторон входят руководители функциональных направлений. Кроме того, в методологии четко прописаны все зоны ответственности, все права каждого из участников проекта. Проектные проблемы разделены на категории, каждой из которых занимается определенная группа сотрудников.
Описать подобную оргструктуру очень важно, но не менее важно то, кто реально войдет в состав административного совета и насколько активно эти люди будут в нем работать.
Несмотря на то, что реализация собственной проектной методологии является для предприятия преимуществом, в ходе реализации проекта она может войти в противоречие с методиками компаний-поставщиков. У них могут быть собственные представления о формировании проектной команды, группы внедрения и т. д. Не существует ли такой опасности?
Мы имеем опыт реализации самых различных ERP-систем на предприятиях нашего холдинга. В качестве примера могу привести небезызвестные в России системы Baan и Scala. Детально рассматривая тонкости функционала этих систем, можно прийти к заключению, что они во многом различаются. Если же ограничиться рассмотрением самых общих вопросов - целей и способов внедрения, - данные системы, наоборот, предстают перед пользователями как очень схожие между собой продукты. То же самое и наблюдается и в области методологических инструментов, разработанных для имплементации указанных систем самими поставщиками. Имея опыт работы и с той, и с другой, мы можем смело утверждать, что внутрифирменные методологии внедрения у них очень схожи.
В "Илим Палп", как я уже сказала, общие подходы к выработке методических приемов внедрения ИС также во многом основаны на универсальных принципах. В результате есть все основания для того, чтобы методологии хорошо стыковались.
Мы, например, на проекте внедрения системы Scala ввели такие понятия, как устав проекта, проектное решение, которых не было у исполнителя.
Вместе с тем подобная "стыковка", конечно же, не происходит сама собой, и здесь очень многое зависит от того, насколько сильную проектную команду мы в данном случае имеем. Иными словами, это вопрос наличия у нее опыта взаимодействия с исполнителем, накопленного в предшествующих работах. Если таковой имеется, есть все шансы адаптироваться под любую методологию.
А что вы подразумеваете, говоря о степени готовности объектов к внедрению?
Поскольку в "Илим Палп" целый ряд промышленных предприятий различного профиля, в нашем случае часто приходится говорить о готовности сразу нескольких объектов (или, если хотите, отдельных предприятий) к внедрению. Это принципиальный момент. Можно выделить, к примеру, методологическую, информационную и техническую готовность. Остановлюсь на первой из них, подчеркнув чрезвычайно важную проблему наличия адекватной нормативно-справочной информации, о которой сейчас вообще говорят постоянно, и очень часто именно в контексте внедрения корпоративных информационных систем.
Неготовность соответствующих справочников очень сильно замедляет ход проекта. Попытка форсировать работы по их созданию уже в ходе выполнения проекта (поскольку вообще без них попросту невозможно его развивать) неизбежно ухудшает качество получаемого решения. Могу сказать, что при внедрении Baan на петербургском картонно-полиграфическом комбинате (КПК), входящем в наш холдинг, справочник готовых изделий переделывался не один раз. Сначала параметры продукции выбирались с ориентацией на точку зрения снабженцев, отвечающих за закупку данной номенклатуры, и соответствующим образом формировался код. Затем, после начала внедрения Baan, выяснилось, что классификатор должен обязательно устраивать и производственников. Стали искать компромисс, и пришлось переделывать весь справочник. А это десятки тысяч позиций.
Иными словами, я хочу подчеркнуть - составление классификатора не только чрезвычайно трудозатратный, но еще и в значительной степени интеллектуальный процесс. Справочник необходимо не просто построить, а построить правильно, адекватно приняв во внимание особенности бизнеса и задач его автоматизации конкретными средствами.
На мой взгляд, особенно остро вопрос стоит именно в холдинговых структурах при формировании централизованных справочников по нескольким предприятиям. В этом случае работа должна быть обязательно проведена до внедрения ИТ-системы силами серьезной команды с включением в нее специалистов с различных объектов.
Данное направление предпроектных работ представляется нам настолько серьезным, что у нас для составления классификационных справочников, их развития и поддержания в непротиворечивом состоянии существует специализированная информационная поддержка. Имеется в виду система коллективного взаимодействия на основе Интернета, предусматривающая встроенные регламенты обсуждения и согласования изменений в ряды номенклатурных позиций. В системе предусмотрены роли инициатора изменений, ответственных за утверждение позиций от каждого объекта (предприятия). Есть механизмы проведения адресных рассылок заранее определенных типов сообщений, форум обсуждения планируемых изменений, процедуры окончательного утверждения.
А другие факторы готовности предприятия к внедрению?
Все факторы мне, наверное, не удастся перечислить. Могу остановиться еще на одном важном аспекте - психологическом. Внедрение системы неизбежно сопровождается для многих сотрудников привнесением новых приемов работы, что создает стрессовую ситуацию во всем коллективе. Я точно знаю, что в некоторых отечественных структурах для решения этой проблемы уже сейчас пытаются привлекать профессиональных психологов. Про наш холдинг такого не скажу, но задача психологической подготовки сотрудников действительно чрезвычайно важна. Она к тому же во многом творческая, и я вряд ли рискнула бы давать здесь какие-либо универсальные рекомендации. В подтверждение этому опять-таки подчеркну особенность решения данной проблемы, если есть несколько объектов внедрения. По личному опыту знаю, что готовить будущих пользователей на предприятиях с унаследованными системами, и там, где новая система ставится "с чистого листа", следует совершенно по-разному.
Из важных аспектов готовности, перечисленных вами в начале беседы, остались, пожалуй, только проблемы классификации и оценки рисков.
Это тоже обширная задача, ведь развернутый перечень рисков в отношении ИТ-проектов занимает у нас несколько страниц. Началось все с того, что после первого проекта внедрения Baan на КПК мы попытались выделить все риски, которые сопровождали данный проект. Мы проанализировали и систематизировали их, составили сводную таблицу и, наконец, включили перечень этих рисков в типовой устав проекта. Он, в свою очередь, является составной частью нашей методологии, о которой говорилось выше.
Важность наличия собственных наработок в данном направлении просто трудно переоценить. Во-первых, приоритеты значения проектных рисков в принципе по-разному расставляются консультантами и заказчиками, о чем, кстати, свидетельствуют и отечественные независимые исследования. Во-вторых, некоторые самые важные с нашей точки зрения риски в принципе могли быть выделены, да и были выделены реально только на основе нашей же собственной практики. Например, это касается риска взаимодействия с консультантами. К сожалению, распространен очень опасный для заказчика сценарий, когда сильные sales-менеджеры "отрабатывают" предпроектную стадию на площадке клиента очень агрессивно, и с точки зрения их роли в проекте весьма профессионально. Приходящие же после них консультанты оказываются на порядок слабее.
По каждому риску у нас предусмотрены его владельцы (те, кто отвечает за минимизацию риска) со стороны ИТ- и бизнес-подразделения заказчика или же со стороны исполнителя, возможные действия по минимизации риска и список мер, которые должны быть осуществлены в случае угрозы реализации риска. По сути, с момента завершения первого проекта с нашей стороны не прекращаются работы по дальнейшей систематизации рисков и разработке ответных действий.
Как я уже сказала, эти регламенты включаются в устав проекта, который, естественно, подписывается как нами, так и исполнителем ИТ-проекта. И в ходе выполнения проекта они фактически предстают перед его участниками в виде совокупности процедур, которых каждый из них обязан придерживаться в случае возникновения рисковых угроз. Таким образом, сформированный на собственном опыте, выстраданный, можно сказать, и отлаженный внутри нашего холдинга механизм по управлению рисками фактически служит универсальным инструментом контроля нежелательных отклонений от регламента проектных работ и одновременно руководством, позволяющий инициировать необходимые корректирующие воздействия. К тому же это "живой", развивающийся инструмент.
