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

С.Н. Колесников, [it_info@iname.com]
кандидат физико-математических наук

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

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

А российские продукты? Легенда гласит, что они более легки во внедрении ? К сожалению, данный тезис не находит подтверждения на практике. При использовании одних и тех же критериев успешного внедрения и при одинаковой функциональности, показатели внедрения примерно одинаковы. Для продуктов, предназначенных для автоматизации крупных компании процент успеха можно оценить в 60 успешных внедрений на 100 продаж, для продуктов автоматизации более мелких компаний - не менее 80. Эти данные косвенно подтверждаются данными по западному ERP рынку Гартнер Групп, которая более осторожно изучает процент соответствия проектов внедрения плановым показателям и оценивает этот показатель для 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 дней, считайте сами, что получится в случае индивидуального обучения.

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

И наконец третий ключевой фактор успех - наличие корпоративных стандартов.

Минимально необходимый набор корпоративных стандартов изложен на врезке.

Типичный перечень стандартов, совершенно необходимых ДЛЯ начала, а лучше ДО начала проекта внедрения -

• организационно-штатная структура предприятия
• бухгалтерские стандарты, включая общий план счетов ДЛЯ ВСЕХ участников проекта, типовой перечень хозяйственных операций, структуру аналитического учета, принципы консолидации данных, корпоративные принципы бюджетного управления и финансового анализа
• кодификатор и классификатор продукции и других товарно-материальных ценностей
• кодификатор и классификатор клиентов и партнеров, созданный с учетом целей анализа товарных и финансовых потоков
• стандарты процедур основных функциональных операций, по крайней мере особо критичных для бизнеса- продажа, закупка, складирование и внутреннее перемещение, и других, изложенных, например, в виде процедур стандарта ISO 9000, особенно если компания планирует его внедрение
• стандарты принятия решений и разрешения противоречий (специфично для России)

Любая интегрированная система управления представляет собой некоторый замороженный срез такого набора стандартов. Естественно в данном случае мы не говорим о простейших бухгалтерских программах - "машинах проводок" или бухгалтерских калькуляторах. Если стандартов нет - то их придется создавать, и не важно, внедряете вы SAP R/3 или 1С. Правда, конечно обьем и уровень детализации будут разными, но принципиальный подход остается тем же - АСУ реализует некоторый вариант описанной и следовательно, хотя бы неформально стандартизованной системы отражения бухгалтерских и хозяйственных операций. Это не исключает возможности и даже необходимости проведения иногда нестандартных или разовых проводок или операций, что конечно система должна позволять делать. Однако утверждение, что "у нас все уникально и нет и не может быть стандартов" как правило оказывается тривиальным нежеланием проводить довольно трудоемкую и требующую высокой квалификации работу. Нужно признать, что работа по созданию корпоративных стандартов, если фирма действительно представляет собой корпорацию, может затянуться на весьма длительный срок, и уж точно будет длиться никак не меньше 4-6 месяцев ( в российской и мировой практике известны случаи, когда этот процесс затягивался ... навсегда ..., особенно если компания не полностью удовлетворяла первому требованию - управляемости)

Но предположим, все вышеперечисленные требования выполнены, что же нужно делать?

Управление проектом.

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

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

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

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

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

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

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

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

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

Региональная политика.

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

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

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

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

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

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

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

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

Особо ответственные справочники, задача стандартизации и унификации которых представляет особую важность для компании:

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

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

финансовая аналитика

данный справочник всегда требует переработки при внедрении автоматизированных учетных систем, особенно западного производства, в связи с другими принципами агрегирования и получения информации по "разрезам аналитики"

клиенты (поставщики и заказчики)

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

склады и политика складирования

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

Если вам удалось дойти до этого пункта , то осталось только ... начать собственно процесс внедрения.

Что осталось "за горизонтом" ...

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

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

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

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

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

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

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

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