Letyshops

Как организовать проект внедрения

Сергей Колесников, кандидат физико-математических наук, ведущий рубрики Consulting.ru
директор по консалтингу Консалтинговой Группы "Экон-профи"

Опубликовано в другой редакции "Как организовать проект по внедрению" в газете ComputeRewiev 9, 1999

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

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

Распространенное мнение, что российские программные продукты более просты во внедрении, чем западные, к сожалению, не подтверждается практикой. Так, успешные внедрения отечественных систем автоматизации крупных организаций составляют 60% от общего числа всех проектов, программных продуктов для более мелких компаний - около 80%. Согласно данным Гартнер Групп по западному рынку, проекты внедрения соответствуют плановым показателям для ERP систем также примерно в 60% случаев (из них "досрочных" внедрений - около 3%), а полностью провалившиеся - составляют 10%. Правда, при этом на Западе учитываются только запущенные проекты, тогда как в России велико количество внедрений, вообще не начавшихся или замороженных на неопределенный срок по форс-мажорным обстоятельствам (например, смена собственника или августовский кризис). К какой категории их относить - неясно.

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

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

Что такое проект внедрения

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

Мы будем применять термин "Система" для обозначения программно-прикладной системы, реализующей функции финансово-экономического управления; "Поставщик/Консультант" - для обозначения консалтингового подразделения поставщика, принимающего участие во внедрении системы, или внешнего консультанта; "Проект" - для обозначения процесса в целом.

Определение стратегических целей Проекта и тактического плана внедрения

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

Предпроектное обследование / промышленный аудит

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

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

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

В России предпроектное обследование часто превращается в платное ознакомление наименее квалифицированного персонала Поставщика / Консультанта с деятельностью предприятия, в результате чего формируется бесполезный документ, якобы описывающий в какой-либо системе моделирования бизнес-процессы Заказчика.

Обучение специалистов группы внедрения

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

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

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

Моделирование бизнеса

Данный этап является необязательным, но обычно рекомендуется в фирменных руководствах по внедрению. Российские Консультанты стремятся использовать этот этап для обучения своих малоопытных специалистов. Однако Заказчику такое "моделирование" практически ничего не дает.

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

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

Разработка и согласование настройки справочников и классификаторов Системы в соответствии с определенными на предыдущих этапах требованиями

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

Настройка Системы в соответствии с принятыми решениями и тестирование функций проектной группой

Здесь также очень важно наличие корпоративных стандартов, потому что именно они являются основой настроек Системы.

Тестовые пуски в отдельных подразделениях

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

Пилотные примеры подразделений: В пилотных примерах подразделений (тестовых или пробных пусках) программное обеспечение используется для имитации работы одного или нескольких тесно взаимосвязанных подразделений. Каждое подразделение обычно выполняет свой собственный пилотный пример.

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

Обучение конечных пользователей работе с Системой

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

Опытно-промышленная эксплуатация

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

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

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

В ходе опытно-промышленной эксплуатации:

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

Ввод Системы в промышленную эксплуатацию

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

Послепроектное обследование / промышленный аудит

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

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

Тест первый.

  1. Знакомы ли вы с российским бухучетом - 2 балла
  2. Знакомы ли вы с Международными стандартами бухучета (или с GAAP) - 3 балла
  3. Знаете ли вы, что такое хозяйственная операция - 1 балл

Если вы набрали 3 или более баллов в этом тесте - у вас хорошие шансы.

Второй тест - ситуационный.

Предположим, что в середине марта, в разгар работы над годовым балансом, вам необходимо отвлечь главного бухгалтера на 1-2 дня для проведения работ по внедрению. Руководитель Проекта дает поручение главному бухгалтеру - его реакция:

  1. Забывает о поручении, положив трубку телефона
  2. После повторного напоминания идет жаловаться вышестоящему начальству
  3. Выполняет немедленно

Гарантии, что Проект будет завершен успешно и вовремя, вы имеете только в третьем случае. Во втором - шанс есть, но скорее всего процесс затянется надолго.

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

  1. Открываете фолиант корпоративных стандартов и читаете соответствующий параграф
  2. После часовых поисков "тетя Маша" находит среди своих "памятных записок" подходящий листочек
  3. Вы безуспешно пытаетесь дозвониться до главного бухгалтера филиала, а когда дозваниваетесь, выясняете, что "Марь Иванна" в отпуске и выйдет через неделю, если успеет убрать всю картошку

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

Окончание в следующем выпуске..

Продолжение в выпусках: #68

 

 

Реклама: