Внедрение информационных систем - практика как критерий истины

ПРОЕКТЫ

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

Пилотный проект

Большой проект по внедрению КИС имеет смысл начать с так называемого пилотного внедрения. Это дает возможность снизить риски проекта, связанные с выбором информационной системы, уменьшить финансовые риски и проверить правильность бюджетных расчетов, наработать методику внедрения и создать сильную проектную группу. При выполнении пилотного проекта можно применить несколько подходов, например, в качестве пилотного выбрать объект, являющийся организационно-структурным элементом компании. Чтобы приобретенный опыт был эффективен при последующем внедрении КИС в других подразделениях, выбранный объект должен удовлетворять следующим критериям:

- функциональная насыщенность и характерность (профиль подразделения должен быть характерен для компании в целом);

- хороший уровень управления и нормальное финансовое положение (это поможет успешному внедрению проекта и гарантирует, что финансово-производственные проблемы его не скомпрометируют);

- оптимальные размеры (подразделение должно быть не слишком большим, чтобы проект не растянулся на длительное время, но и не очень маленьким, иначе результаты проекта могут оказаться малозаметными в масштабах всей компании);

- относительная простота бизнес-процессов подразделения (задачей пилотного проекта является не апробирование всех возможностей внедряемой информационной системы, а демонстрация ее работоспособности, создание базовой модели бизнеса и отработка методики внедрения).

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

Таким образом, правильное определение сферы и задач пилотного проекта - важная составляющая успеха как самого пилотного проекта, так и последующего применения накопленного опыта и наработок при “большом” внедрении.

Управленческие аспекты внедрения информационной системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дмитрий Коротков - консультант KPMG Global Solutions Delivery, Франкфурт. К нему можно обратиться по адресу: dkorotkov@rbcmail.ru.