Этапы внедрения ERP. Внедрение ERP-систем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Строение IT-системы планирования ресурсов предприятия

Являясь сложным программным обеспечением, ERP система состоит из следующих элементов:

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

Модули, подключаемые к основной платформе системы планирования ресурсов производства, условно делятся на три группы:

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

Где взять ERP систему для предприятия

Существует три способа приобрести ПО для планирования ресурсов:

1. Создание собственного продукта . Зачастую оказывается нерациональным методом, поскольку отсутствие профессионального подхода может привести к возникновению ситуации, когда будет учтено только одно направление, что не даст ощутимого эффекта. При этом внедренную таким способом систему, как правило, сложно заменить или дополнить.
2. Покупка готовой платформы и внедрение ее в работу предприятия . Тут необходимо сделать правильный выбор в соответствии с деятельностью вашей компании. Качественные и известные продукты стоят довольно дорого и требуют постоянной поддержки со стороны разработчика.
3. Профессиональная разработка ERP систем индивидуально для компании . Только 20% создаваемых на отечественном рынке программ успешно интегрируются в работу предприятий. А значит риск компании получить некачественный продукт по завышенной стоимости достаточно большой.

Как выбрать и внедрить ERP систему

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

Виды ERP систем для предприятий

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

По виду организации выделяют системы следующих форматов:

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

По типу хранения информации:

• Облачные - базы данных располагаются на внешних серверах.
• Внутренние - данные хранятся на собственном сервере компании.

По формату пользовательского интерфейса:

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

По архитектуре программного обеспечения:

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

По классу лицензии на использование:

• Проприетарная - закрытое ПО, для использования которого требуется оплатить лицензию.
• Open Source - бесплатные программы с открытым исходным кодом.

Ошибки выбора системы планирования ресурсами

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

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

Какие функции должна обеспечивать система планирования ресурсов

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

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

Особенности внедрения ERP

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

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

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

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

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

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

Как работает ERP система и кому она необходима

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

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

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

Краткий обзор популярных ERP

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

Популярные бесплатные продукты:

• ERPNext - минималистичная программа для работы частного предпринимателя (ИП). Основной недостаток - ограниченное дисковое пространство, которое можно увеличивать за дополнительную плату.
• Галактика ERP - разработана под отечественный рынок и позволяет учитывать частые изменения в законодательстве.

Платные программы:

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

Достоинства и недостатки ERP

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

Отрицательные стороны интеграции системы планирования ресурсов

Несмотря на то, что назначение ERP систем - это улучшение процесса деятельности производства, они имеют свои недостатки. В числе последних:

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

Практические достоинства ERP-системы

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

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

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

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

Рынок систем ERP (Enterprise Resource Planning – «планирование ресурсов предприятия») остается одним из самых быстрорастущих рынков программного обеспечения в мире. Объем российского рынка ERP system по итогам 2015 года вырос, по данным TAdviser, на 9%, достигнув 108 млрд (см. рисунок). Выручка 8 из 10 крупнейших игроков отечественного ERP-рынка также показала за отчетный период положительную динамику.

Рисунок

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

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

Скачайте полезные документы :

Ошибка №1. Не описать бизнес-процессы до начала внедрения ERP

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

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

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

Ошибка №2. Постоянно вносить изменения в будущую систему

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

Ошибка №3. Полностью полагаться на автоматизаторов

Верить, что автоматизаторы все сделают за вас не стоит. Не сделают и точка. Не смогут учесть всех особенностей вашей компании, нюансов взаимодействий и тонкостей ведения бизнеса. Каждая компания индивидуальна. Хотите получить хороший результат – подключайтесь к проекту внедрения EPR-системы с самого начала! Команда проекта обязательно должна включать ключевых специалистов компании, что значительно снизит риск неудачи проекта и позволит создать инструмент управления, полезный для компании, а не «систему ввода данных для отчетов». Помните о цели внедрения – повышения операционной эффективности компании.

Ошибка №4. Разработать ТЗ на все случаи жизни

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

Ошибка №5. Не учитывать сопротивление персонала

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

Ошибка №6. Не уделять достаточно внимания проекту внедрения ERP-системы

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

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

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

Ошибка №7. Пытаться сделать сразу все

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

Ошибка №8. Выбрать неподходящую платформу

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

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

Ошибка № 9. Неправильная команда автоматизаторов

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

Ошибка №10. Некорректные цели внедрения ERP-системы

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

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

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