Внедрение ERP-решений

Внедрение IT-решений обеспечивает широкие возможности оптимизации процессов. К таковым можно отнести удалённый доступ к данным и знаниям, основанный на веб-технологиях, функционал ERР- систем, используемых для широкого круга компаний, систем OSS/BSS для поддержки телекоммуникационного бизнеса. Важную роль в выполнении процессов играют эффективные организационные структуры и системы мотивирования персонала. В рамках этого направления можно отметить создание команд процессов, формирование их ключевых показателей и основанной на них бонусной системы, разработку соответствующей системы мотивирования команды, формирование организационной структуры компании, основанной на процессном принципе.

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

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

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

Для успешного внедрения ERP-системы нужно придерживаться следующих правил:

1. Точно знать цели проекта, т. к. 70% проектов терпит неудачу именно по этой причине.

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

3. Проектная команда должна быть обеспечена всем необходимым для выполнения проекта (проектным офисом, компьютерами, принтерами, телефонами и т. д.).

4. Проект должен быть разбит на логически выверенные этапы и фазы работ, которые должны быть проверены на отсутствие "конфликтов" в последовательности и продолжительности работ.

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

Достоинства и недостатки ERP- решений

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

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

Основные недостатки ERP-систем:

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

Следует оценить не только знание внедряемой системы, но и глубокое знание предметной области применения системы, знание специфики отрасли Заказчика, а также умение управлять такими сложными проектами:

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

Высокая и стоимость внедрения, т. к. значительная доля затрат на внедрение ERP приходится не на стоимость системы, а на работы по ее внедрению;

Высокая стоимость владения ERP-системой (ежегодные затраты);

Долгая окупаемость системы - 2-3 года после ее внедрения .

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

Технологии также могут различаться: в одних случаях проводится продолжительная подготовительная работа, полное документирование всех требований, проектирование и реализация доработок, и лишь затем – внедрение 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 система, а также о том, в каких случаях внедрение этой программной системы принесет реальную пользу, и на что обращать внимание при выборе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 был максимально эффективным.

Процесс внедрения 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 Запуск системы в промышленную эксплуатацию

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

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

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

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

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

Ошибка №1. Проектирование системы ERP без учета стратегии развития компании

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

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

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

Ошибка №2. Проектирование системы ERP "снизу-вверх"

Заложить в ERP-систему цели компании и перспективы ее развития можно только при проектировании "сверху-вниз", а не наоборот. Создание информационной управленческой системы - удовольствие дорогое. Регистрация в ней всех данных, появляющихся в компании, в принципе невозможна. И естественно, каждый разработчик при проектировании сталкивается с необходимостью перехода от этого полного, в некотором смысле "неограниченного" объема информации к какому-то лимиту". Поэтому, создавая ERP-систему, проектировщик всегда решает задачу выбора значимых для принятия управленческих решений данных в увязке с "ценой вопроса" на ее реализацию. На каждом предприятии ежедневно циркулируют огромные информационные потоки данных о материально-технических ресурсах, клиентах, персонале, производственном потенциале и т.д. Возникает вопрос: нужны ли в ERP-системе специфические сведения, скажем, о производительности какого-либо станка в последние 2 часа или о количестве полуфабрикатов на столе конкретного работника в текущий момент при том. что эта информация, бесспорно, используется в управленческой деятельности?

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

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

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

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

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

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

Ошибка №3. Избыточный реинжиниринг бизнес-процессов

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

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

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

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

Ошибка №4. Неверная оценка экономической эффективности внедрения ERP-системы

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

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

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

Технология и практика проектирования ERP-систем.

На практике процесс проектирования выглядит следующим образом: Заказчик формулирует укрупненные требования к создаваемой системе, которые ложатся в основу Концепциии Технического задания, разрабатываемых внешней проектной организацией. Этому процессу всегда предшествует анализ производственно-хозяйственной деятельности компании-заказчика. Цель изучения бизнес-процессов - определение "узких мест" в информационном обеспечении и выявление резервов для повышения эффективности работы компании. На основе вариантных проработок в Концепции определяется контур создаваемой системы, а именно: базовая ERP-система; функциональная структура; информационное обеспечение; количество необходимых автоматизированных рабочих мест; техническое обеспечение. При разработке Концепции особое внимание уделяется перспективам развития бизнеса заказчика. Рамки, в пределах которых важно понимать (представлять) перспективы развития бизнеса, определяются исходя из сроков разработки и внедрения системы (которые зависят от масштабов компании: от 6 месяцев до 3 лет); периода функционирования системы без необходимости ее модернизации (желательно, чтобы период морального старения системы составлял не менее двух лет). Сформированная на основе предпроектного обследования Концепция может содержать несколько основных альтернативных вариантов развития автоматизации системы управления заказчика. Каждый вариант должен быть оценен исходя из соотношения "стоимость/эффективность". Выбор Концепции осуществляется заказчиком и служит основой для разработки Технического задания (ТЗ). Здесь детально прорабатываются требования к системе. ТЗ - основной документ, определяющий требования, организацию и проведение работ, в соответствии с которыми осуществляется проектирование ERP-системы и ее сдача заказчику. Следующий этап - разработка модели бизнес-процессов to be (бизнес-процессы в условиях функционирования ERP-системы). Модель создается на основе ТЗ и укрупнено описывает управленческие и информационные взаимосвязи в системе. Данный этап является ключевым в работах по созданию ERP-системы. Это объясняется тем, что его результаты позволяют сформировать у сотрудников и руководства компании-заказчика видение функционирования их предприятия в условиях использования ERP-системы и уточнить требования к ней. Для крупных компаний целесообразна разработка Эскизного проекта (до разработки модели бизнес-процессов to be), в котором определяются основные проектные решения (с количеством рабочих мест свыше 60). На основе ТЗ, проектных решений, утвержденных на этапе эскизного проектирования, и модели бизнес-процессов to be осуществляется техно-рабочее проектирование. На данном этапе должен быть проведен анализ соответствия алгоритмов расчетов и методов управления, заложенных в программном обеспечении внедряемой ERP-системы, специфическим алгоритмам и методам, применяемым в практике функционирования компании-заказчика. По результатам анализа определяются "пробелы" в функциональности системы и принимаются необходимые проектные решения по их устранению. Эффективность проектов по созданию и внедрению комплексных автоматизированных систем управления тем выше, чем теснее сотрудничество заказчика и разработчика на всех этапах проектирования.ЕХНОЛ