Внедрять ли ERP-систему в вашей компании? Внедрение ERP Системы на предприятии

Внедрение ERP-системы для вашего предприятия – стоит ли его проводить, пора или ещё нет? Обычно руководитель фирмы решает использовать такие системы в следующих случаях:

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

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

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

Типичные проблемы при внедрении ERP-продуктов

Принимая решение использовать ERP, предприятие сталкивается со следующими трудностями:

• Уровень программного обеспечения не соответствует реальным потребностям фирмы: оно или слишком сложное, или недостаточно мощное.
• Громоздкое ПО не настраивается под бизнес, а требует настроить бизнес под него.
• Для обслуживания продукта нужно нанять многих специалистов или оплатить услуги сторонней компании. Рядовые сотрудники компании не могут работать с приобретённым ПО из-за нехватки квалификации.

Работающая стратегия внедрения ERP

Как снизить стоимость внедрения ERP? Самый верный способ – перестать зависеть от команды разработчиков и привлекать их для выполнения всех видов работ. Если предприятие способно само обслуживать и настраивать приобретённую им систему, то очевидно, что затраты снижаются. С целью применения данной практики стоит пойти по следующему пути:

• Первый этап – определяем цели внедрения ERP и желаемый результат, которого вы хотите достичь. Если нет чёткого понимания целей, то как потом определить, эффективно решение или нет?
• Второй этап – выбор конфигурации продукта. Хорошо, когда продукт не «монолитный», а состоит из множества элементов, чтобы их было можно добавлять, убирать и трансформировать.
• Далее – запуск системы на вашем предприятии. Если компания способна самостоятельно справиться с задачей установки, то это приводит к гигантской экономии ресурсов: времени и финансов.

Как найти ERP систему для вашего уровня бизнеса

Подобрать систему, не слишком сложную для фирмы, но способную развиваться по мере её роста – непростая задача. Мы предлагаем вам попробовать готовое на базе Comindware Business Application Platform. Типовое ERP-решение от Comindware имеет ряд отличий от привычных продуктов:

• Доступно по цене.
• Подходит для большинства компаний, как крупных, так и не очень.
• Если у вас есть IT-отдел, его специалисты сами справятся с внедрением и настройкой. Процесс внедрения ERP системы в случае с Comindware не предполагает обязательного привлечения сторонних наладчиков.
• Универсально для автоматизации всех бизнес-процессов, затрагивающих финансы, кадры, производство и маркетинг.
• Помогает быстро автоматизировать наиболее востребованные для компании бизнес-процессы.
• Корректировки системы внедряются без остановки работы.
• При необходимости развивается до уровня классической системы ERP.

Попробуйте Comindware Business Application Platform бесплатно, чтобы затем принять взвешенное решение. и оцените сами, насколько вам это подходит.

Если у вас возникнут проблемы с внедрением ERP систем на базе Comindware Business Application Platform, мы обязательно поможем их устранить и всё наладить. Таким образом, внедрять ли ERP-систему в вашей компании, зависит не от уровня развития компании, а от уровня способности конкретной ERP системы адаптироваться под её текущие нужды. Если возможности системы соответствуют потребностям предприятия, то её использование можно считать правильным шагом.

Дополнительная информация о Comindware Business Application Platform и демонстрация решения доступны по запросу

Елена Гайдукова, маркетолог-аналитик, бренд-менеджер решений на базе , специалист по партнёрским отношениям.

(32%). После того, как выбор сделан, популярность систем остается сопоставимой: 21%, 18% и 14% соответственно (имеются ввиду те случаи, когда указанные платформы выбираются для внедрения).

В целом сроки ERP-проектов остаются по-прежнему одной из болезненных проблем для данного рынка: только 36% отметили, что смогли уложиться в заранее отведенные временные рамки, а 62% - существенно вышли за них, и только 3% смогли завершить проекты внедрения раньше намеченного. Больше всего выбивались из графика проекты на базе решений Microsoft Dynamics, в среднем они длились 12,5 месяцев, что 4 месяца (47%) больше, чем было запланировано.

Проекты на базе Oracle в среднем длились 22,5 месяца, перерасход времени здесь составлял 29% против в среднем запланированных 17,5 месяцев. Что касается SAP ERP, то средняя длительность таких внедрений составила 18,5 месяцев с минимальной задержкой на 16% или 2,5 месяца против 16 месяцев, запланированных изначально.

Средняя длительность ERP-проектов: запланированная и реальная

Panorama Consulting, 2014

Основные причины задержек ERP-проектов

Panorama Consulting, 2014

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

Хорошей новостью стало, пожалуй, только то, что в период с 2012 по 2013 годы аналитики зафиксировали снижение среднего срока окупаемости проектов ERP с 2,4 лет до в среднем 1,7 лет. Тем не менее, количество организаций, которые вообще не смогли окупить свои вложения в автоматизированные системы управления ресурсами предприятия, выросло с 31% до 38%. Наиболее долгий период окупаемости выявлен у решений Microsoft Dynamics (24 месяца), у SAP он составляет 23 месяца, у Oracle - 16 месяцев.

И еще один важный момент: фактический бюджет проектов относительно планируемого по итогам 2013 года опять увеличился. Наиболее дорогим внедрением при этом является внедрение SAP ERP , в среднем бюджет такого проекта составляет $2,55 млн, затем следуют Oracle - $2,25 млн, Microsoft Dynamics - $1,8 млн. От годового оборота предприятий внедрение Tier I систем составляет 2-4%, а вот доля стоимости ERP-проектов на базе Tier II и III может быть существенно выше в обороте компаний, выбравших их для внедрения.

Только 66% компаний смогли добиться хотя бы 50% целей

Что касается ERP-проектов в целом (безотносительно конкретных вендоров), то по итогам 2013 года только 66% компаний смогли добиться хотя бы 50% намеченных целей в рамках внедрений. В 72% случаев проект оказался больше по срокам, чем планировалось ранее при средней длительности 16,3 месяцев. В 54% случаев был зафиксирован перерасход бюджета, средний бюджет проекта составил $2,8 млн.

Средние показатели ERP проектов 2012-2013

Panorama Consalting, 2014

63% признали реализованные ERP-проекты успешными, 21% затруднились оценить эффект от внедрения, 16% признали, что внедрение окончилось неудачей.

Российские реалии

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

• лишь 32% проектов завершились успешно,
• 44% испытали различные трудности (превысили бюджет, выпали из сроков и пр.),
• 24% проектов просто провалились.

На российском рынке ситуация едва ли лучше, отмечают эксперты компании «Первый БИТ ».

Статистикой «успешности» ERP-проектов поделились в компании 1С . По данным исследования 555 выполненных внедрений ERP -решений фирмы «1С» в 2010-2013 годах:

• 66% проектов уложились в срок или имеют незначительное, до 10% отклонение от срока,
• 24% проектов отклонились от срока на 11-30% и
• только 10% проектов отклонились от срока более, чем на 30%.

Что касается бюджетов проектов, то тут ситуация для заказчиков еще более обнадеживающая:

• 78% проектов укладываются в бюджет или имеют превышение бюджета не более, чем на 10%,
• 19% проектов имеют превышение бюджета на 11-30% и
• только 3% проектов имеют превышение бюджета более, чем на 30%.

Среди основных причин неудач ERP-проектов российские интеграторы выделяют:

Завышенные ожидания

Большая проблема, когда нет чёткого понимания желаемого результата, чего заказчик хочет добиться, отмечает Ефим Фиш , директор по развитию бизнеса Microsoft Dynamics AX Tops Consulting (Топс Консалтинг) . В этом случае, перефразируя известное изречение, проект нельзя закончить, его можно только прекратить. Зачастую заказчики неправильно оценивают свои желания и требуемые затраты. Обе стороны должны согласовать между собой цели проекта и ключевые моменты в отношении того, что необходимо для успешной реализации проекта.

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

Человеческий фактор, отсутствие поддержки руководства

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

В 1С, например, для соблюдения сроков проекта используют методику под названием «Технология Быстрого Результата» (ТБР). Согласно статистике сроков внедрений ERP-решений фирмы «1С» (1420 проектов за 2010-2013 годы), в среднем, до ввода первой подсистемы в опытную эксплуатацию проходит около 3 мес., а до ввода последней подсистемы в промышленную эксплуатацию от 6 до 10 мес. в зависимости от масштаба проекта. На особо крупных предприятиях внедрение может длиться и 1-2 года.

Как уточнил Алексей Петрушов, одним из основных показателей неэффективности проекта является затяжка сроков. Основной причиной этой проблемы, безусловно, является человеческий фактор, добавил он.

* Оплата после внедрения. Успешного внедрения.

«Мы не ищем "виноватых" (виноваты всегда обе стороны) в неудачных внедрениях, мы берем деньги с заказчика, только когда он удовлетворен результатом» - говорит Сабина Борщевская, eBusinessDrive . Мы выполняем внедрение ERP , практически, за свой счет, и, если результат клиента не устраивает - он просто не платит. На текущий момент подобные условия на российском, и уж тем более мировом, рынке внедрения ERP-систем свежи как воздух в горах Швейцарии. Приходите.

Нехватка или перерасход бюджета

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

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

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

Информационные системы планирования ресурсов предприятия (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-системы, специфическим алгоритмам и методам, применяемым в практике функционирования компании-заказчика. По результатам анализа определяются "пробелы" в функциональности системы и принимаются необходимые проектные решения по их устранению. Эффективность проектов по созданию и внедрению комплексных автоматизированных систем управления тем выше, чем теснее сотрудничество заказчика и разработчика на всех этапах проектирования.ЕХНОЛ

Для начала о самом проекте: внедрение 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 одну и ту же задачу можно решить различными способами, то разные консультанты используют разные методы, и в итоге система начинает «расползаться». Никакие «совещания по итогам дня» здесь не помогают, потому что из-за объема разных вопросов консультанты многое к вечеру уже просто забывают.

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

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