Внедрение автоматизированной системы бюджетирования
Методология внедрения
Этапы и шаги проекта внедрения
Контрольные точки и документирование проекта
Анализ требований
Планирование проекта
Проектирование бюджетной модели
Настройка системы
Тестирование системы
Развертывание системы
Оценка результатов проекта
Внедрение любой серьезной информационной системы, по сути дела, представляет собой инвестиционный проект: средства, вложенные в покупку лицензий и оплату услуг консультантов, с течением времени должны принести предприятию вполне реальные экономические выгоды. Иначе говоря, вложенные средства должны не только окупаться, но и приносить прибыль. В то же время любому финансисту хорошо известно, что инвестиции экономически эффективны лишь тогда, когда они сделаны осознанно, в соответствии со стратегией развития предприятия и определенной технологией инвестирования.
Сказанное в полной мере относится к проектам внедрения информационных систем. Ни покупка лицензий, ни оплата услуг консультантов сами по себе не могут гарантировать успех проекта. Успех приходит лишь тогда, когда выбор системы сделан осознанно, а внедрение ведется по определенным правилам. К сожалению, и в мире, и в России накоплен большой отрицательный опыт неудачных проектов, и главная причина неудач - нарушение методологии внедрения. Вот почему вопросы проработки проекта и его грамотной организации всегда находятся в центре внимания консультантов, приступающих к внедрению информационной системы.
Методология внедрения
Важность методологии внедрения признают и сами разработчики автоматизированных систем, при этом у крупных компаний-разработчиков считается "правилом хорошего тона" иметь свои собственные методические рекомендации. Подходы разных компаний имеют много общего (что неудивительно, поскольку все они основаны на общих принципах управления IT-проектами), но при этом каждый из них учитывает специфику предметной области (т.е. того, для чего внедряется система), а также особенности того или иного программного продукта. Практическая ценность таких методик заключается в том, что они являются результатом обобщения позитивного опыта, накопленного консультантами в ходе многочисленных проектов, поэтому следование этим рекомендациям позволяет существенно снизить риски проекта.
Примером может служить методология, разработанная корпорацией Hyperion Solutions и получившая название STAR (Structured Techniques for Assured Results), что на русский язык можно перевести как структурированные приемы, обеспечивающие надежный результат.
Как и любая методология, STAR представляет собой набор принципов, подходов и рекомендаций по внедрению, которые применимы ко всем системам Hyperion, включая системы планирования и бюджетирования (Hyperion Planning, Hyperion Pillar), системы стратегического управления (Hyperion Performance Scorecard), системы бизнес-моделирования (Hyperion Business Modeling), системы консолидации финансовой отчетности (Hyperion Financial Management, Hyperion Enterprise). По сути, STAR представляет собой пошаговое руководство, организованное в соответствии с этапами работ и содержащее как требования к документированию внедрения, так и практические рекомендации по выполнению работ в рамках той или иной фазы проекта.
В соответствии с методологией STAR проект внедрения предусматривает семь этапов, которые мы рассмотрим применительно к внедрению системы бюджетирования:
анализ требований;
планирование проекта;
проектирование бюджетной модели;
настройка системы;
тестирование системы;
развертывание системы;
оценка результатов проекта.
Каждый этап включает несколько шагов, которые выполняются в определенной последовательности. При этом шаги могут выполняться как последовательно (когда следующий шаг выполняется только после завершения предыдущего), так и параллельно (когда два или более шагов выполняются одновременно). Взаимосвязь шагов схематично может быть изображена так, как показано на рисунке.
/------\ /------------------------\ /-----------------------------\
|Анализ| |Анализ бизнес-требований| |Анализ технических требований|
| | \------------------------/ \-----------------------------/
|------| \---------------------------------/
|Плани-|
|рова- | /--------------------------\
|ние | |Формирование плана проекта|
| | \--------------------------/
| | /--------------------------------------------\
| |
| | /---------\ /----------\ /-----------\ /------------\
| | |Концепту-| |Установка | |Определение| |Планирование|
| | |альное | |оборудова-| |стратегии | |обучения, |
| | |проекти- | |ния и ПО | |тестирова- | |обучение ра-|
| | |рование | | | |ния | |бочей группы|
| | \---------/ \----------/ \-----------/ \------------/
|------| \------------/ | |
|Проек-| |
|тиро- | /----------\/----------\ | /------------\
|вание | |Планиро- ||Проектиро-| | |Формирование|
| | |вание при-||вание ин-| | |плана обуче-|
| | |ложений и||теграцион-| | |ния |
| | |отчетов ||ных реше-| | |
| | | ||ний | /----------\ | |
| | \----------/\----------/ |Подготовка| \------------/
|------| |плана тес-|
|Наст- | /----------\/----------\ |тирования | /------------\
|ройка | |Создание ||Интеграция| \----------/ |Формирование|
| | |приложений||и автома-| | |программы |
| | |и отчетов ||тизация | | |обучения и|
| | | || | | |учебных |
| | | || | | |групп |
|------| \----------/\----------/ | \------------/
|Тести-| \-------------/ |
|рова- | | /------------------\ |
|ние | \------|Тестирование | |
| | \------------------/ |
| |
| | /-----------------\ /----------------\
|------| |Параллельное тес-| |Обучение пользо-|
|Разве-| |тирование |--|вателей |
|ртыва-| \-----------------/ \----------------/
|ние |
| | /-----------------\
| | |Промышленная экс-|
| | |плуатация |
| | \-----------------/
| | /------------------------\
|------|
|Оценка| /-----------------\ /----------------\
| | |Анализ итогов| |Текущее обучение|
| | |проекта | |пользователей |
\------/ \-----------------/ \----------------/
Этапы и шаги проекта внедрения
Контрольные точки и документирование проекта
В соответствии с методологией STAR на каждом этапе выделяются контрольные точки, позволяющие определить статус проекта, оценить имеющиеся риски и более четко спланировать дальнейшие действия. При этом особенно внимательно следует относиться к пересмотру графика работ и изменению рамок проекта.
Кроме того, STAR предусматривает определенные требования по документированию проекта, включая прежде всего наиболее важные проектные и управленческие решения. Эти требования также основаны на общепринятых принципах консалтинга и аудита, в частности, изложенных в международном стандарте аудита ISA 230 "Документирование". Требования STAR в части документирования являются результатом анализа и обобщения наиболее успешных проектов, выполненных как консультантами Hyperion, так и другими компаниями. Методологией предусмотрен дифференцированный подход к проектам, поскольку относительно небольшие внедрения требуют гораздо меньшего документирования по сравнению с крупными и большими проектами.
Для реализации требований по документированию корпорацией Hyperion разработаны шаблоны документов, доступ к которым осуществляется через Интернет. Это дает возможность всем консультантам, работающим с системами Hyperion, воспользоваться уже имеющимися наработками.
Рассмотрим перечисленные выше этапы и шаги проекта более подробно.
Анализ требований
Цель анализа - получить максимум информации о заказчике и специфике его задач, уточнить рамки проекта, оценить возможные риски, а также (и это очень важно) сформировать проектную группу, на которую будет возложена значительная часть предстоящих работ.
На данном этапе происходит идентификация принципиальных требований методологического и технологического характера, формулируются цели и задачи проекта, а также определяются критические факторы успеха, которые впоследствии будут использоваться для оценки результатов внедрения. Анализ требований выполняется на основе совещаний и собеседований с руководителями и специалистами заказчика, а продолжительность этого этапа в зависимости от сложности задач и масштаба внедрения может составлять от нескольких дней до нескольких недель.
Определение и описание требований (методологических и технических) - шаги, которые во многом определяют успех всего проекта, поскольку именно они влияют на все остальные этапы. Практика показывает, что недостаточная проработка требований зачастую проявляется лишь тогда, когда проект почти завершен, а значительная часть ресурсов, выделенных на его реализацию, уже затрачена. К сожалению, устранение проблем на этапе разработки обходится гораздо дороже, чем тщательная проработка на стадии анализа.
Планирование проекта
Данный этап представляет собой начало непосредственного внедрения. Главным итогом этапа является укрупненный план проекта, содержащий основные фазы и контрольные точки. При этом важно предусмотреть наиболее важные ресурсы, которые понадобятся в ходе проекта, и распределить их в соответствии с планируемыми работами. Более детальный план разрабатывается позже, на этапе проектирования, а отдельные изменения будут вноситься на этапах разработки, тестирования и развертывания системы. Для формирования плана и последующей работы с ним рекомендуется использовать специализированное программное обеспечение календарного планирования, например Microsoft Project.
Помимо разработки укрупненного плана проекта на данном этапе производится так называемое концептуальное проектирование - разработка прототипа будущей системы. Прототип предназначен для того, чтобы предоставить членам проектной группы и конечным пользователям возможность смоделировать работу будущей системы и взаимодействие ее компонентов. Как правило, прототип представляет собой демонстрационный пример, разработанный на основе бизнес-требований, сформулированных на этапе анализа. Это позволяет убедиться, что требования к системе сформулированы правильно, а в случае необходимости следует внести соответствующие уточнения и корректировки, которые затем будут учтены при проектировании модели.
Еще одна задача, решаемая на данном этапе, - формирование проектной группы и ее обучение. Это важный момент, поскольку общий успех проекта (да и последующей эксплуатации системы) во многом зависит от степени участия и квалификации персонала заказчика.
Кроме того, на этапе планирования разрабатываются стратегия тестирования и стратегия обучения конечных пользователей, которые впоследствии будут работать с системой. Производится также установка необходимых технических средств и программного обеспечения в соответствии с техническими требованиями, определенными на этапе анализа.
Проектирование бюджетной модели
На данном этапе происходит детальная методологическая и организационная проработка будущей системы бюджетирования. Здесь важно учесть все существенные требования к будущей системе и определить, каким образом они будут реализованы. На этом же этапе прорабатываются интеграционные аспекты: определяются "смежные" системы (учетные, ERP, OLAP и др.), с которыми должен происходить информационный обмен, а также данные, которые должны приниматься и передаваться системой бюджетирования.
Важно, чтобы этап проектирования проходил при максимально активном участии проектной группы. К сожалению, на практике это требование не всегда выполняется, и предприятия зачастую полагаются на опыт внешних консультантов. Не следует забывать, что никто не знает предприятие лучше, чем специалисты самого предприятия, поэтому именно их роль в формировании бюджетной модели позволяет избежать досадных (и дорогостоящих) ошибок и неточностей.
Настройка системы
Этап настройки предусматривает трансформацию концепции, разработанной на предыдущей стадии, в реальную информационную систему. Зачастую именно этот этап оказывается наиболее длительным и дорогостоящим. Вполне возможно, что в ходе настройки будут выявлены какие-либо ошибки и неточности постановочного характера. В этом случае допускается частичный пересмотр принципов бюджетной модели, построенной на стадии проектирования. Таким образом, развитие проекта приобретает "спиралевидный" характер: происходят параллельные доработка и развитие проектных решений и настроек системы. Впрочем, в случае тщательного формирования исходной бюджетной модели количество уточнений и доработок не бывает слишком большим.
В ходе уточнения и развития бюджетной модели необходимо тщательно контролировать произведенные изменения и версии, а также оценивать их возможное влияние на календарный график проекта и его стоимость.
Тестирование системы
Этап тестирования позволяет убедиться в том, что настроенная информационная система в точности соответствует утвержденной методологии бюджетирования и согласованным организационным требованиям. На данном этапе выявляются разного рода несоответствия, после чего проводится корректировка настроек системы. Параллельно с тестированием происходит обучение конечных пользователей и, возможно, привлечение некоторых из них к процессу тестирования.
Имеет место заблуждение, что тестирование автоматизированной системы гарантирует ее качество. На самом деле, это не так: тестирование позволяет лишь оценить уровень качества, но вовсе не является средством достижения необходимого качественного уровня.
Развертывание системы
После завершения тестирования система признается готовой к запуску в эксплуатацию, т.е. к вводу ее в действие для всех пользователей. Как правило, именно этот этап является для предприятия наиболее "болезненным", поскольку для персонала запуск новой системы неизбежно связан с повышенными нагрузками. Кроме того, именно на начальной фазе эксплуатации системы наиболее вероятны ошибки и неточности, не выявленные в ходе тестирования. Если до внедрения предприятие уже использовало какую-либо систему бюджетирования, то можно организовать параллельную работу двух систем - старой и новой. В этом случае риски ошибок будут сведены к минимуму, но нагрузка на персонал еще более повысится.
Развертывание системы может происходить разными способами в зависимости от решаемой задачи и количества пользователей. Общее правило - постараться минимизировать риски, связанные с использованием нового программного обеспечения. Для крупных внедрений, когда количество пользователей и охваченных подразделений достаточно велико, обычно практикуется пилотное внедрение, при котором система развертывается на ограниченных участках (например, в отдельных подразделениях). Пилотная стратегия имеет ряд достоинств: неудобства переходного периода максимально смягчаются, влияние возможных негативных последствий минимизируется, а нагрузка на рабочую группу не носит лавинообразного характера. Но при этом сам переходный процесс оказывается растянутым во времени.
Для относительно небольших внедрений может быть применен принцип "большого скачка" - все подразделения переводятся в режим промышленной эксплуатации одновременно. Но такой подход применяется только в случае, когда число пользователей и подразделений невелико, кроме того, пользователи должны быть хорошо подготовлены в части знания системы и своей роли в новой автоматизированной среде.
Оценка результатов проекта
Наконец, последняя стадия проекта - подведение его итогов. Это необходимо для того, чтобы убедиться в соответствии внедренной системы потребностям предприятия и тем целям и задачам, которые были сформулированы на начальных стадиях проекта. Работа, проделанная в ходе проекта, позволяет и руководителям, и специалистам предприятия по-новому взглянуть на процессы управления и, возможно, определить направления дальнейшего совершенствования управленческих технологий, которые могут быть реализованы в будущем.
Как правило, оценку результатов проекта рекомендуется проводить в течение одного месяца после перевода системы в промышленную эксплуатацию.
Итак, методология STAR представляет собой достаточно емкое и детальное руководство по организации процесса внедрения. В то же время она оставляет консультантам, ведущим проект, определенную степень свободы и позволяет подойти к его организации довольно гибко. Не секрет, что проекты могут значительно различаться по масштабам, уровню сложности и другим факторам, и именно поэтому внедренческие компании далеко не всегда применяют STAR в ее "первозданном" виде. Как правило, опытные специалисты по внедрению вносят в проект изменения и дополнения, позволяющие наиболее полно учесть специфику внедряемого решения и особенности конкретного заказчика. Но, с другой стороны, такие модификации исходной методологии должны быть основаны не только на здравом смысле, но и на общих принципах проектного менеджмента и их особенностях для проектов внедрения информационных технологий.
Д. Исаев,
Д. Хомаза
Холдинг Ланит
"Финансовая газета", N 18, апрель 2004 г.
Если вы являетесь пользователем интернет-версии системы ГАРАНТ, вы можете открыть этот документ прямо сейчас или запросить по Горячей линии в системе.
Газета "Финансовая газета"
Учредители: Министерство Финансов Российской Федерации, Главная редакция международного журнала "Проблемы теории и практики управления"
Газета зарегистрирована в Госкомпечати СССР 9 августа 1990 г.
Регистрационное свидетельство N 48
Издается с июля 1991 г.
Индексы 50146, 32232
Адрес редакции: г. Москва, ул. Ткацкая, д. 5, стр. 3
Телефон +7 (499) 166 03 71