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

Вступление
Что такое проект внедрения
Ключевые факторы успеха
Управление Проектом
Региональная политика
Что осталось «за горизонтом»...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тест первый.

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

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

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

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

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

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

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

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

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

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

Поддержка Проекта

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

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

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

Квалифицированный персонал

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

Так как получить подобную сумму непросто, многие Поставщики пытаются спрятать эти деньги или вовсе отказаться от предварительного обучения, ссылаясь на то, что оно пройдет «на рабочих местах». Это действительно возможно и практикуется — но только для конечных пользователей, которым нужно знать только несколько последовательностей клавиш. Проектная группа должна изучить все концепции программного продукта и взаимосвязь между ними — только тогда она сможет успешно вести Проект. На этом и играют недобросовестные Поставщики: если нет обученного персонала, больше будут привлекаться Консультанты. Но обучение все равно придется проводить, но оно обойдется дороже, так как стоимость курса в учебном центре для одного сотрудника компании-клиента примерно равна или больше стоимости рабочего дня консультанта, а курс — 3-5 дней.

Корпоративные стандарты

Третий ключевой фактор успеха Проекта — наличие корпоративных стандартов. Стандартный набор их приведен на врезке

Любая интегрированная система управления представляет собой срез такого набора стандартов (конечно, мы не говорим о простейших бухгалтерских программах: «машинах проводок» или бухгалтерских калькуляторах). Если стандартов нет, их надо создавать, и не важно, внедряете вы SAP R/3 или 1С. Объем и уровень детализации могут быть разными, но принципиальный подход один: АСУ реализует некоторый вариант описанной и, следовательно, хотя бы неформально стандартизованной системы отражения бухгалтерских и хозяйственных операций. Система должна позволять делать нестандартные или разовые проводки, но утверждение, что «у нас все уникально и нет и не может быть стандартов», как правило, объясняется тривиальным нежеланием выполнять трудоемкую и требующую высокой квалификации работу.

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

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

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

Первая задача, которую нужно решить — сформировать управляющий комитет Проекта. Он должен иметь полномочия и возможность выполнять следующие задачи:

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

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

Кроме того, в рамках отдела ИТ (АСУ) нужно создать группу, которая будет поддерживать функционирование Системы как программного продукта во время и после ее внедрения. Минимальное количество специалистов, необходимое для поддержания работоспособности Системы, полностью интегрирующей все управленческие функции среднего или крупного предприятия (при односменной работе) — 4-6 человек. Среди них должен быть один системотехник (то есть специалист по взаимодействию прикладных задач и операционно-управляющих систем), один специалист по поддержке Базы Данных и программированию и несколько специалистов по прикладным подсистемам. В группу не входят специалисты по поддержанию работоспособности локальной вычислительной сети и технических средств связи. Также не учтен персонал, необходимый для ввода данных при «неполном охвате» или «неполной интеграции» Системы, что часто встречается при отечественной любви к «экономии». Естественно, в каждом подразделении, должны быть выделены и подготовлены «квалифицированные пользователи», обеспечивающие поддержку эксплуатации функциональных блоков продукта. В компании со сложной структурой необходим дополнительный персонал для разработки и поддержания в актуальном состоянии учетных/управленческих стандартов предприятия. Таких специалистов можно ввести в состав экономических подразделений (бухгалтерии, планового отдела) или создать для них самостоятельное подразделение.

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

Степень детализации корпоративных стандартов зависит от уровня интеграции финансовых и бизнес-процессов головной организации и подразделений. Наиболее простой вариант — чистый холдинг, то есть группа независимо хозяйствующих субъектов, результаты работы которых, как правило, консолидируются и оцениваются раз в год на уровне некоторого итогового (специального) плана балансовых счетов. Эта форма пока редко используется в отечественной практике, так как отсутствует распространенная (принятая) методика консолидации учета, которая исключала бы внутрихолдинговые обороты. Наиболее сложный вариант — «распределенное» предприятие, состоящее из нескольких территориально существенно удаленных филиалов, ведущих сложную хозяйственную деятельность, например производственных. Его использование усложняется типичным для России отсутствием хороших скоростных каналов связи.

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

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

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

• Кодирование/классификация товаров, материалов и компонент;
• классификация поставщиков;
• классификация заказчиков;
• учетная нумерация/классификация первичных документов;
• методы и особенности нумерации частей и компонентов готовой продукции (структуры изделия).

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

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

Приоритетные задачи автоматизации — поддержка планирующих и управляющих технологий, а не отчетных (во всех смыслах) процедур. Дело в том, что многие, если не все, отчеты можно получать и более простыми, в том числе ручными, методами, и, как правило, очень сложно бывает объяснить руководству, почему для их создания нужен дорогостоящий продукт. Для систем планирования ручная поддержка гораздо более трудоемка.

Руководство и специалисты заказчика умеют применять или, по крайней мере, имеют представление о стандартных технологиях управления бизнесом, таких как SIC, MRP, Supply Chain, TQM и тому подобных. Им не требуется специальное обучение в случае использования таких элементов в Проекте (по крайней мере, в части технологий, уже применяемых заказчиком). Именно по этой причине в России предварительное обучение, причем на уровне консультантов по внедрению, является обязательным условием успешной реализации Проекта.

Работает иерархическая структура управления, то есть распоряжения руководства обязательны для исполнителей.

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

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

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