На сегодняшний день тема внедрения ERP-систем на предприятии довольна актуальна не только из-за малой изученности этого вопроса, но также из-за бурного развития прикладных информационных систем. Последние 20 лет число компаний внедряющих подобные системы увеличивается каждый день, а количество компаний, испытавших на себе положительный эффект от работы ERP растёт по экспоненте. Также отличным показателем развития данной отрасли рынка служит рост компаний поставляющих ERP-системы и консалтинговых компаний, занимающимися их внедрениям. Так, например, клиентская база SAP, немецкой компании по производству программного обеспечения, только за последние 10 лет увеличилась с 17500 до 91500 клиентов, а годовой доход в 2012 году составил 15 млрд евро.

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

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

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

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

Рис. 2. Схема организации планирования процессов в масштабе предприятия

При внедрении систем управления компания получает целый ряд преимуществ:

Прежде всего -- это стабильность и унификация всех процессов управления предприятием. Системы класса ERP представляют собой интегрированные системы управления, то есть:

  • · они не связаны с производственным процессом непосредственно, не являются автоматизированными системами управления технологическими процессами, но имеют дело с моделью технологического процесса;
  • · их работа состоит в улучшении деятельности предприятия, в оптимизации материальных и финансовых потоков на основе вводимой на рабочих местах информации;
  • · в одной системе охватывается планирование и управление ВСЕЙ деятельностью производственного предприятия, начиная от закупки сырья и заканчивая отгрузкой товара потребителю;
  • · информация вводится в систему только один раз в том подразделении, где она возникает, хранится в одном месте и многократно используется всеми заинтересованными подразделениями.

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

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

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

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


Рис. 3.

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

Информационная система планирования ресурсов предприятия является довольно развитой системой и функции ее находятся в постоянной стадии разработки и усовершенствования, но все же, случается так, что после того, как ERP-система была внедрена на определенном предприятии и все методики ее внедрения были задействованы правильно, руководству предприятия по-прежнему не удается получить полный информационный контроль над деятельностью предприятия. И что самое интересное, ничего существенного не происходит, а даже наоборот, все остается по-прежнему. В чем же здесь дело? Факторов, влияющих на некорректную работу ERP-системы может быть много. Это может быть, к примеру, некорректное оформление первичных документов, сбои и нарушения в политике сбыта, наличие на предприятии сверхнормативных запасов. Возможны даже случаи того, что многие предприятия после внедрения ERP-системы, отказываются от нее, по причине того, что якобы она неадекватно и несвоевременно реагирует на поставленные перед ней задачи. Но так дело обстоит не только на наших предприятиях, есть сведения, что и на западе на долю успешных внедрений ERP-системы на предприятиях приходится менее 50% случаев.

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

В прошлой статье я рассказывал о том, Что такое ERP система, а также о том, в каких случаях внедрение этой программной системы принесет реальную пользу, и на что обращать внимание при выбореERP. А сейчас я хочу поговорить о том, как получить практическую пользу от ERP-системы. А для этого программный продукт необходимо внедрить.

Я уже писал о внедрении программных продуктов в серии статей «Внедрение программного продукта. Особенности работы бизнес-консультанта». И многие рекомендации из этой серии статей можно применять также при внедрении ERP. Но все же эта система предназначена для среднего и крупного бизнеса, а потому и внедрение ее имеет определенные особенности из числа тех, что в прошлых статьях, посвященных преимущественно малому и среднему бизнесу, я не раскрывал. Еще одна важная особенность ERP – это многофункциональная, сложная система с очень широким функционалом, и при внедрении этот факт также необходимо учитывать.


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


О том, как вести проект внедрения ERP-системы от и до, я также постараюсь рассказать в следующих статьях. А сейчас я хочу поговорить о самом важном – начале внедрения.

Разные подходы к внедрению

Существует несколько подходов к внедрению ERP-систем, которые я видел в чужом исполнении и/или сам применял на практике. Каждый из них имеет свои плюсы и минусы, какие-то «подводные камни» и преимущества.


В принципе, все подходы к внедрению ERP, также актуальны для любых сложных систем, например, 1C УПП, 1С ERP, SAP Bussines ONE, ODOO и др. Давайте о них поговорим подробно.

Подготовка технического задания

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


Как это реализуют:

  1. Создается объемное техническое задание, в котором по максимуму продуманы и описаны все процессы, включая самые мелкие.
  2. Под техническое задание создается календарный план работ.

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


От такого подхода плюсы получают, прежде всего, разработчики:

  • Документ Техническое задание будет стоить дорого. Выполняется большой объем работы, занимающий значительное время. И заказчики обычно соглашаются с высокой ценой техзадания без каких-либо вопросов.
  • Разработчики получают подробную инструкцию, на основе которой можно проводить работы. А в случае неудачных решений, имеющихся в подписанном ТЗ, переделки будут оплачиваться отдельно.

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


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


В моей практике был случай, когда я пришел на предприятие обсуждать внедрение нового программного продукта (я был руководителем проекта), и мне представители бизнеса прямым текстом говорили: «Хватит с нас технических заданий. У нас этих документов уже – больше, чем надо». И действительно, показали объемные папки с документами, решения из которых так никогда и не были реализованы.

«Частичное» внедрение

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


В этом случае техническое задание также имеется. Как и календарный план при варианте работы, где за основу берут объемное ТЗ. Но здесь техническое задание не является таким всеобъемлющим, возможно составление для разных этапов работы собственных технически заданий. Т.е. основной документ в данном случае – План выполнения работ.


Например:


В качестве первого этапа внедрения выбираем участок Финансы и Движение товаров. Этот участок работ является очень важным для любой компании. Разбираемся с особенностями движений финансовых в организации, изучаем хранение и продажу товаров. На основе этого составляем ТЗ для автоматизации в ERP выбранного участка. И внедряем необходимый для этого участка функционал.


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


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


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


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


Также при первом методе работы по автоматизации работы разных подразделений могут проводиться параллельно. Клиент будет видеть автоматизацию и бухгалтерии, и продаж, и склада, и производства. Здесь же работа проводится этап за этапом. И подразделения подключаются к ERP также по очереди.

«Agile» подход

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


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


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


Основной плюс такого метода – работа по внедрению начинается сразу после принятия решения. Без длительной подготовки. Именно это и привлекает бизнесменов. Например, было принято решение – автоматизируем отдел продаж – сразу приступили к работе. Решили – надо перенести остатки – тут же они переносятся.


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


Минусы – отсутствие планирования комплексного внедрения. Здесь проблемы возникают практически по тем же причинам, что и при составлении всеобъемлющего ТЗ: ERP – сложный комплексный программный продукт, и ошибки при внедрении одного модуля могут повлиять на работу другого модуля. Но если в первом случае такие проблемы возникают из-за попытки заранее предусмотреть слишком много, то здесь – по причине отсутствия планирования. Т.е. специалисты при внедрении решают сиюминутные задачи, не задумываясь о том, что на следующем этапе им потребуются данные и документы из текущего модуля для организации работы другого подразделения.


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

«Понемногу, но все и сразу»

Еще один подход к внедрению ERP я лично называю “Понемногу, но все и сразу”. Этот вариант также вполне может быть успешным и удобным решением. Я лично его применял не один раз. И если при частичном внедрении в работу берут один или два модуля, полностью их настраивают, и только потом приступают к работе над другими модулями, то в этом случае работа также ведется постепенно, то нет такого четкого ограничения - только этот модуль и никакие другие.


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


В самом общем случае подобный план выглядит следующим образом:

  1. Разработка технического задания.
  2. Выполнение работ согласно технического задания… Этот пункт может быть детализирован, выполнение работ тогда делится на несколько этапов.
  3. Тестирование системы.
  4. Ввод в эксплуатацию.
  5. Обучение персонала.
  6. Завершение (сдача) проекта.

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


Такой метод удобнее и реалистичнее, чем составление технического задания, так как общее ТЗ для всего проекта потребует 2-3 месяцев работы или даже больше, а полученный в результате объемный документ со всеми подробностями заказчику изучить будет очень сложно.


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


Плюсы такого подхода:

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

Минусы подхода:

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

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


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


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

С каких модулей начинать?

Количество модулей, которые может предложить систем ERP, вызывает нередко вопросы, с чего же начать, ведь возможностей очень много, как говорится, «глаза разбегаются». Я рекомендую начинать с наиболее критичных для работы компании направлений и связанных с ними модулей:

  1. Финансы и взаиморасчеты. (Не путайте с бюджетированием – этот модуль можно и нужно внедрять позже, он относится к планированию, а не к текущей критически важной работе).
  2. Движение товарно-материальных ценностей (ТМЦ): хранение, реализация, поступление. Очень важно, чтобы ТМЦ учитывались корректно, перед переносом остатков обычно проводят инвентаризацию, далее – переносят остатки, после чего работа ведется уже только в новой системе.
  3. Бухгалтерский учет. Внедрение модуля бухучета или организация обмена данными с бухгалтерской системой. Государство ничего не прощает, и за любое нарушение, независимо от наличия умысла, предусмотрено наказание. А потому бухгалтерский и налоговый учет – также система, критичная для работы любой компании.

Иногда я слышу возражения, что у компании могут быть свои нюансы, например, в связи с высокой текучкой кадров наиболее критичным является HR. На самом деле, скорей всего, какая-то автоматизация работы HR в компании на момент начала внедрения ERP имеется. И независимо от того, насколько критична для бизнеса работа этого подразделения, некоторое время управление персоналом можно будет вести в той системе, которая есть. А если в процессе будут выявлены определенные ошибки – это будет минусом, но не самым критичным для существования компании.


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


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


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


Теги: Добавить метки

Для начала о самом проекте: внедрение 1С:ERP на промышленном предприятии. Когда мы пришли к клиенту (в 2015г), численность завода составляла 5 тысяч человек. За время проекта завод существенно вырос и нарастил объемы производства, сейчас на нем работает порядка 6,5 тысяч сотрудников. 1С установлена на 1,2 тыс. рабочих мест. Активно работающих пользователей сейчас (июнь 2017г) порядка 350, планируется увеличение до 450ти.

Предприятие входит в военно-промышленный комплекс России, и, следовательно, имеет свою специфику.

До этого проекта я запускала средние предприятия (1000-1500 сотрудников, 50-150 рабочих мест). Делать их мы уже научились, выработав четкую методологию (сейчас у меня с командой среднее время перевода проекта в промышленную эксплуатацию 7-10 месяцев, в зависимости от его сложности.)

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

Итак, по порядку. На завод мы пришли в конце 2015г. Изначально стояла задача запуска регламентированного учета. По ходу функционального моделирования руководство Заказчика (с подачи главного бухгалтера) приняло решение о передачи функции ввода первичных документов «на места». Границы проекта были пересмотрены, включив в себя центральные склады, кладовые, цеховую бухгалтерию, управление договорами и БДДС. Сроки внедрения регламентированного учета были сдвинуты на 2017г, а в течение 2016г автоматизировалась «первичка».

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

Если честно, то я думала, что главной сложностью будет саботаж со стороны пользователей. До внедрения 1С те ничего никуда централизованно не вводили: кто-то работал в Excel, кто-то - в самописных системах. Основой документооборота были «бумажки», которые потом сдавались в АСУП для ввода операторами в бухгалтерскую программу. Здесь проектная команда со стороны Заказчика грамотно подошла к вопросу – был выпущен ряд приказов, подписанных генеральным директором, которые закрыли проблему. Приказы оформлялись не в привычном стиле «на нашем предприятии запускается система…», а были вполне конкретными «с такого-то числа бухгалтерия принимает от складов только документы, выписанные из 1С». Для снятия возможного недопонимания мы сразу включили штриховое кодирование документов и раздали бухгалтерии сканеры (реально были попытки сдать документы, «нарисованные» людьми в Word).

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

Первая (хотя и не основная) проблема была вполне предсказуема – это объемы данных. Однако масштабы ее я изначально недооценила. Для примера – просто загрузка (безо всякой обработки) остатков по «малоценке» занимает около 4х суток. А если по итогам вдруг обнаруживаются расхождения, то еще четверо суток, а потом еще.… То есть этот этап работ надо при планировании очень тщательно прорабатывать вместе с заказчиком, буквально по дням. Например, здесь мы пошли по обычному пути: загрузили только справочники и посадили пользователей бить «первичку», чтобы после окончания загрузки остатков, все провести, проверить и выйти на оперативный учет. В итоге мы физически не успели до конца месяца свести учет и начислить погашение стоимости, и чтобы сдать управленческую отчетность, пришлось руками переносить из старой системы суммы затрат, а потом их корректировать из-за разных методик учета.

Так же многих нужных данных в нормальном виде у заказчика нет, и соответственно просить их подготовить надо сильно заранее: например, список открытых заказов нам начали собирать за три (!!!) месяца. Казалось бы, чего уж проще? Предприятие должно владеть информацией, что кому и когда оно должно произвести и отгрузить. Но, как оказалось, в формализованном виде у них были только номера заказов (требование по организации раздельного учета по Гособоронзаказу), а наименование продукции, количество, сроки и т.д. хранились либо где-то в Excel, либо в бумажных договорах.

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

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

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

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

Отдельно стоит упомянуть организацию информирования пользователей программы. Надо заранее встраивать в конфигурацию модули для вывода обязательных сообщений: обзвонить 350 человек и сказать, что обновилась инструкция или что сегодня будет запускаться расчет себестоимости, нереально. Здесь нам сильно помогла заплатка из БСП (библиотека стандартных подсистем).

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

Как я работала до этого: по каждому процессу определялся его Владелец, который формировал по нему требования, мы разрабатывали схему работы, проходились по ней с ключевыми пользователями, после чего утверждали у владельца. Обычно такая методика хорошо закрывает 80% операций, а оставшиеся 20 «подрихтовываются» на этапе опытно-промышленной эксплуатации. По этому пути мы пошли и здесь. Разница между реальностью и представлениями руководителей отделов проявилась практически сразу же. Но начальники говорили «не может быть!», а подчиненные в силу корпоративной культуры им не возражали. В итоге утвержденная схема работы содержала часть слишком трудоемких операций, много избыточных контролей и не содержала определенного количества того, «чего у них точно не бывает». Все это пришлось переделывать в ходе опытно-промышленной эксплуатации. Уже реализованные и сданные доработки в итоге были кардинально переписаны, а сама ОПЭ потребовала постоянного присутствия программистов.

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

Анализируя, по итогам, проект, я пока не вижу способа особо снизить риск значительного расхождения между описанными процессами и реальностью: чтобы подробно проработать схему с каждым подразделением, а потом еще – с их руководителями, бюджет Функционального моделирования придется увеличивать в 5-7 раз, а заказчикам обычно сложно понять ценность данного этапа и заплатить 25% от стоимости проекта просто за «бумажку». Была мысль о тестовом прогоне системы на нескольких подразделениях, которую я попробовала на другом проекте, но в полной мере она себя не оправдала.

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

Третья проблема проекта вытекает из первых двух: большое количество пользователей (для которых нужно много консультантов) и большое количество проектных решений, которые принимаются прямо на этапе ОПЭ. А так как в ERP одну и ту же задачу можно решить различными способами, то разные консультанты используют разные методы, и в итоге система начинает «расползаться». Никакие «совещания по итогам дня» здесь не помогают, потому что из-за объема разных вопросов консультанты многое к вечеру уже просто забывают.

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

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

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

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

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

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

Как же найти оптимальный вариант внедрения?

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

Необходимо начать с того, что бросаться, очертя голову, во внедрение ERP не следует. В любом случае потребуется определенная подготовительная работа, и, конечно, составление плана работ. Существуют ГОСТы на автоматизированные системы, которые предполагают прохождение некоторых этапов и составление проектных документов для внедрения системы. До какой степени нужно следовать рекомендациям ГОСТов на каждом конкретном предприятии – решать службе ИТ. Следует помнить, что эти документы разработаны уже достаточно давно, и они описывают создание автоматизированной системы «с нуля», а не внедрение готового программного продукта. Если специалисты ИТ-службы разрабатывают собственную систему – альтернативы ГОСТам по сути нет. А что делать, если используется готовая тиражная ERP-система?

В такой ситуации вариантов несколько:

  • Взять ГОСТы и попробовать самостоятельно адаптировать их с учетом специфики предприятия и текущих нужд;
  • Силами ИТ-службы разработать собственный порядок внедрения системы;
  • Выработать порядок внедрения совместно с Партнером 1С, либо воспользоваться готовым предложением Партнера.

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

Как выбрать Партнера для комплексной автоматизации?

Фирма 1С работает со множеством крупных и мелких компаний-интеграторов. Как выбрать «своего» – такого, который не подведет?

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

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

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

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

Выбрав Партнера, необходимо определиться с вопросом о порядке внедрения в эксплуатацию функциональных подсистем ERP.

Как внедрять?

Что лучше – последовательная автоматизация отдельных бизнес-процессов и функциональных подсистем, или же внедрение системы сразу целиком на всем предприятии?

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

С каких же функциональных подсистем целесообразнее начать, чтобы как можно быстрее получить все плюсы внедрения ЕРП-системы?

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

Аналогичным образом решается ситуация и с подсистемами Кадров и Зарплаты. В подавляющем большинстве случаев на старте проекта автоматизации на предприятии эти задачи решаются в отдельной конфигурации «1С:Зарплата и управление персоналом», и могут быть перенесены в ERP-систему на более поздних этапах проекта.

При внедрении необходимо учесть, что, наряду с транзакционными задачами, на автоматизированные системы может возлагаться управление процессами. Так, транзакция «Проведение в системе документа Заказ поставщику» может являться результатом продолжительного процесса формирования потребностей, уточнения номенклатуры и условий закупки, рассмотрения предложений поставщиков, согласования и утверждения стоимости заказа, решения логистической задачи и т. д. Таким образом, вокруг этого документа может проходить достаточно сложный процесс. Если документ, как таковой, на практике применим для большинства предприятий, то окружающие его процессы уникальны для каждой конкретной организации. В этом случае функционал «1C:ERP» целесообразно дополнить бесшовно интегрируемым решением «1С:Документооборот».

Бесшовная интеграция позволяет пользователю работать в «1C:ERP» и при этом пользоваться функционалом «1С:Документооборот», даже не запуская эту программу. Внесение бизнес-процессов в «1С:Документооборот» помогает отслеживать, на каком этапе находится каждый из процессов, какие действия необходимо предпринять в текущий момент в системе и за ее рамками, какие документы оформить и с кем их согласовывать и т.д. Кроме того, интеграция ERP и документооборота дает возможность согласовать работу разных подразделений, проводить встречи и совещания, вместе работать над выполнением принятых решений, фиксировать ход работ через документы автоматизированных систем, определять достигнутый результат.

Кроме того, «1С:Документооборот» поможет, если для отражения той или иной специфической операции предприятия в «1C:ERP» не предусмотрен необходимый документ. Такой документ можно сформировать в «1С:Документооборот», а затем включить в бизнес-процесс.

Подробнее о стоимости, функционале и внедрении 1С ERP вы можете узнать

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

Процесс внедрения ERP-систем условно делится на 7 этапов: организационные работы, обследование предприятия, выбор методологии автоматизации, проектирование системы, развёртывание ПО на рабочих местах сотрудников, запуск системы в промышленную эксплуатацию, сопровождение.

Предлагаем рассмотреть порядок внедрения ERP более подробно.

I Организационный этап

Работа над проектом внедрения ERP на предприятии начинается с определения цели и задач . Это не должна быть автоматизация ради автоматизации - заказчик должен чётко знать, каких бизнес-эффектов он в итоге желает достичь.

На подготовительном этапе также необходимо сформировать рабочую группу на стороне клиента. В неё должны войти:

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

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

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

II Этап обследования предприятия

По завершении организационных работ проводится обследование бизнес-процессов предприятия. Данная процедура необходима для точного определения сроков и стоимости внедренческих работ. В зависимости от масштабов проекта и поставленных задач IT-интегратор может предложить клиенту один из 2-х вариантов обследования:

  • Экспресс-обследование . Проводится в течение 1,5–2 месяцев. По его итогам составляется документ «Предпроектный анализ». В нём отражаются особенности автоматизированного учёта и перечень задач, которые необходимо будет решить в процессе внедрения.
  • Полное обследование . Проводится в течение 3–5 месяцев. По итогам досконального обследования составляется «Техническое задание», разрабатываются бизнес-процессы автоматизированного учёта и описывается перечень необходимых доработок ПО.

Выбор варианта обследования определяется предпочтительной методикой внедрения ERP.

III Выбор методологии внедрения ERP

Внедрение ERP-решений на платформе «1С:Предприятие» может осуществляться по одному из 4-х сценариев:

  • Абонентское обслуживание . Компания-интегратор проводит экспресс-обследование предприятия, составляет укрупнённый план внедрения ERP и на основе него определяет максимально возможную стоимость проекта. Эта стоимость прописывается в договоре, там же фиксируется стоимость одного часа работы программиста-внедренца. Общий план работ разбивается по месяцам. Исходя из количества рабочих часов определяется размер ежемесячного бюджета. Фиксированная сумма платежа также вносится в договор.
  • Поэтапная технология внедрения . Данная методология внедрения ERP подразумевает проведение полного обследования предприятия, определение всех автоматизируемых бизнес-процессов и подготовку ТЗ. В техническом задании отражаются: объёмы доработок типовой конфигурации программы, полный перечень работ с разбивкой на фиксированные этапы, сроки и стоимость реализации каждого этапа внедрения ERP. Главный минус данной технологии - негибкость. Внесение мельчайшей корректировки в проект влечёт за собой изменение ТЗ: пересмотр сроков и стоимости выполнения отдельных этапов работ.
  • Технология быстрого результата . Алгоритм внедрения ERP примерно тот же, что и при абонентском обслуживании. Так же проводится экспресс-обследование, рассчитывается максимальная стоимость проекта, оценивается час работы программиста. Оплата так же осуществляется раз в месяц, но не по фиксированному тарифу, а по количеству реально затраченных программистами часов. Строго регламентированных планов работ на месяц, неделю здесь нет - список и очерёдность выполнения задач может меняться в зависимости от актуальных потребностей предприятия. Гибкость является безусловным плюсом технологии быстрого результата. Включить в проект дополнительные бизнес-процессы можно на любом этапе и без длительных согласований. Единственным недостатком данной схемы внедрения является размытость сроков реализации проекта.
  • Разовые вызовы . Установка программы на рабочие места сотрудников и автоматизация бизнес-процессов осуществляются по мере возможностей клиента. Предприятие закупает коробку, а все внедренческие работы проводятся по сценарию разовых вызовов.

IV Проектирование системы ERP

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

V Внедрение ERP-системы на предприятии

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

VI Запуск системы в промышленную эксплуатацию