Предыдущие статьи были посвящены описанию ERP системы, ее структуре и функциям, какую пользу она может принести программной системе и по каким признакам ее выбирать. В данной же статье речь пойдет о том, как собственно извлечь пользу из этого продукта. А для того, чтобы из него что-либо извлекать, сначала эту систему нужно внедрить.
В моем арсенале есть уже статьи и внедрении программных продуктов. В частности, в них говорилось о бизнес-консультанте и особенностях его работы. Некоторые материалы из данных статей применимы и к внедрению ERP, но все же здесь есть ряд своих особенностей.
Данная система разработана для среднего и крупного бизнеса, а все предыдущие статьи имели отношение преимущественно к малому бизнесу. К тому же, при внедрении ERP, следует не забывать о многофункциональности данной системы. А функционал у нее достаточно широк по сравнению с остальными программными продуктами.
Внедряя какой-либо программный продукт, многие пользователи, прежде всего, задаются вопросом: «а с чего же начинать»? Ведь именно от правильного начала и грамотного подхода зависит весь процесс внедрения, пройдет ли он гладко или возникнут трудности и переделки. Само собой полученный результат повлияет на бизнес.
О принципах работы с ERP-системой, ее особенностях, этапах реализации и ошибках, допускаемых в работе с ней, будет рассказано в следующих статьях, а пока мы рассмотрим о начале внедрения продукта.
Существует несколько подходов к внедрению ERP-систем, которые я видел в чужом исполнении и/или сам применял на практике. В каждом из них есть масса своих особенностей, плюсов и минусов, нюансов. Следует отметить, что все изученные подходы одинаково рекомендованы и для других сложных систем, таких как, 1C УПП, 1С ERP, SAP Bussines ONE, ODOO и др. Наша же статья посвящена ERP-системе, поэтому о ней и пойдет дальше речь.
Общее внедрение.
ERP-система является очень технологичным продуктом. Поэтому и разработчики, и пользователи стараются максимально подготовиться к внедрению еще до его начала. С одной стороны, это выглядит разумно, так как сложную программную систему лучше изучать поэтапно. И в принципе данный подход вполне пригоден для использования.
Создание объемного технического задания с подробным описанием всех процессов, в том числе и самых мелких.Этапы реализации данного подхода:
- Создание календарного плана работ, подчиняющегося техническому заданию.
Первый этап реализации подхода может занять несколько месяцев. По опыту своих наблюдений приходилось видеть специалистов, которые тратили на эту процедуру около 6 месяцев. Причем, им приходилось постоянно приезжать на место внедрения, вносить переделки и замечания в документы. Конечно, при таком подходе разработчики остаются в плюсе по следующим причинам:
- Составление технического задания стоит немало, так как процесс довольно трудоемкий и продолжительный по времени. Но заказчики, как правило, соглашаются со всеми условиями, так как самостоятельно этот процесс они вряд ли осилят.
- Разработчики заранее требуют от заказчиков прописать инструкцию, по которой они в дальнейшем будут работать. Если возникать необходимость добавить или переделать что-то, чего нет в инструкции, то за это взимается отдельная плата. А это еще одна статья прибыли.
Главным минусом подхода можно назвать его сложность и большой объем работы. Создать с первого раза идеальное со всех сторон техническое задание, при этом прописав в нем все модули, документы и нюансы будущей работы, нереально. Многофункциональность системы приведет к тому, что при внесении изменений в один модуль, потребуется менять и все остальные. Иными словами, изменения вносятся сразу во всю систему, что не совсем рационально. При возникновении недоработок и необходимости переделок придется менять всю систему, возникнет путаница и, как следствие, отказ от проекта. Последнее не понравится ни заказчику, ни разработчику.
Тоже касается и ошибок при составлении технического задания, исправление которых непременно затронет все модули программы. Допустим, при внедрении какого-то бизнес-процесса выясняется, что загружена совсем не та документация, которая требуется. А случилось это лишь от того, что разработчики неверно поняли инструкцию. И для того чтобы исправить ошибку, придется поменять кучу информации в очень сложной системе. Однако, такие ошибки все равно будут.
Даже я столкнулся с ситуацией, когда собирался на одном из предприятий внедрять новый программный продукт. Еще на этапе обсуждения проекта руководители бизнеса предъявили мне несколько толстых папок с техническими заданиями, из которых ни одно не было реализовано. И тогда мне, как руководителю проекта, ответили, что им технические задания больше не нужны. И их тоже можно было понять, ведь эти толстые папки заняли кучу времени на то, чтобы их составить, а потом еще попытаться реализовать.
Поэтапное внедрение.
Данный подход заключается в обозначении наиболее важных направлений и модулей, которые должны быть включены в программу. Этот список потом и становится планом по внедрению системы.
Здесь также составляется техническое задание, но оно имеет меньший объем. К тому же можно для каждого этапа работы формировать свое задание. Основным документом здесь будет план выполнения работ.
Приведем несколько примеров:
Допустим, первым этапом внедрения мы определили модуль Финансы и Движение товаров. Данные участки являются значимыми для любого предприятия. Изучаем нюансы движения финансовых потоков, хранение и продажу товаров. Основываясь на полученных знаниях приступаем к формированию технического задания по внедрению ERР на данных участках. Далее непосредственно совершаем внедрение и формируем необходимый функционал.
Затем берем под рассмотрение участок производства, проводим те же самые манипуляции уже с учетом проведенных работ в сфере финансов и движения товара.
Плюсом такого подхода является его близость к реальности, так как объять необъятное сразу очень тяжело. А вод поэтапное продвижение значительно облегчит процесс, позволить избежать крупных ошибок и переделок всей системы. К тому же при таком подходе можно будет сразу увидеть и оценить работу системы уже на этапе внедрения. Я, признаться, сам склоняюсь к этому варианту действий.
Минусом подхода является его затянутость во времени, которая может не совсем понравиться заказчику. При частичном внедрении сроки проведения работ могут затягиваться как по объективным причинам, так и по разных поводам, связанным с финансированием, человеческим фактором и т.д. Кроме того, если руководитель бизнеса стремится получить все и сразу, его также может не устроить отсутствие точных данных о внедрении (когда будет завершено, какова будет точная сумма и т.д.).
В данном подходе приходится проявлять больше осторожности, что естественно отражается на сроках внедрения.
«Agile» подход.
Отличается отсутствием подготовительного этапа. Процесс сразу начинается с внедрения. Такой подход сразу может показаться провальным, так как ERP-система очень сложна, чтобы начинать ею пользоваться без подготовки. Однако, и такая практика имеет место быть в некоторых компаниях.
Плюс такого подхода заключается в сжатых сроках его реализации, чем он и привлекает компании. Допустим, решили провести автоматизацию какого-либо отдела, сразу взяли и провели, и работаем. Нужно перенести остатки – взяли и перенесли, и дальше работаем.В данном случае разработчики действую по принципу «давайте решать проблемы по мере их поступления». Разрабатывают некий общий план внедрения, который потом делится на части. Такую тактику действий предпочитают мелкие продавца, которые используют коробочный вариант программы. Их основная прибыль строится на продаже программы, а ее внедрение это уже отдельный бонус, причем платный.
С другой стороны и такой вариант действий тоже бывает успешным, однако требуется наличие профессионалов высокого уровня в руководстве, а также большой опыт в таких проектах. Но даже при таком раскладе профессионалы могут выбрать другой путь действий, потому как при данном варианте наибольший процент ошибок и влияния человеческого фактора. В этом и заключается минус подхода. Так как даже в первом случае при всеобщем внедрении возможны ошибки, а без планирования их становится еще больше. Ведь даже когда мы рассматривали первый вариант действий, то пришли к выводу, что там будет много недоработок. И это при четком планировании, а здесь его вообще нет. Иными словами, разработчики, внедряя свой программный продукт, сосредоточены на решении сиюминутных задач, не задумываясь о том, что при реализации следующего этапа им понадобится обратиться к старым данным и документам из текущего модуля для организации работы другого подразделения.
Поэтапный и всеобщий одновременно.
Такой вариант тоже может пригодиться. Его отличие от поэтапного внедрения заключается в том, что здесь работают над каждым модулем отдельно, но изменяют сразу все модули. На поэтапном, как говорилось ранее берутся один-два модуля и разрабатываются. Здесь также составляют план проекта. В этом плане основными этапами считаются не модули (один, потом — другой и т.д.), а какие-то виды работ, которые могут затрагивать одновременно все модули или выборочно какие-то из них. При этом для каждого этапа указываются примерные сроки и стоимость.
Разработка технического задания. В самом общем случае подобный план выглядит следующим образом:
- Выполнение работ согласно технического задания. Здесь возможно создание детального описания каждого процесса, выполнение работ тогда делится на несколько этапов.
- Тестирование системы.
- Ввод в эксплуатацию.
- Обучение персонала.
- Завершение (сдача) проекта.
Также составляют отдельные планы для каждого модуля, что помогает разработчикам определиться со стоимостью каждого этапа работы и сроки ее выполнения. При этом с заказчиком обязательно оговаривается возможность в процессе внедрения в случае необходимости изменить какие-то виды запланированных работ другими.
В данном случае удобство метода состоит в его реалистичности и отсутствия необходимости составлять техническое задание, не придется тратить месяцы работы на составление ТЗ и не будет толстого пакета документов, которые обойдутся заказчику не дешево.
Данный подход позволяет заказчику оценить свои финансовые и физические возможности при работе с каждым из модулей. Для него все прозрачно. К тому же для каждого этапа создается свое техническое задание, причем на данный процесс уходит мало времени. При необходимости доработки модуля не придется затрагивать всю систему, изменения можно внести здесь и сейчас. Желательно еще и называть каждый из документов понятным образом. Например, «Бухгалтерия и финансы» или «Отдел продаж».
Преимущества данной тактики заключаются в следующем:
- Заказчику доступно полное обозрение ситуации. Он может самостоятельно и полноценно оценить сроки и стоимость своего проекта.
- Разработчик дает четкую оценку стоимости своих работ, что позволяет сэкономить значительную часть времени на обсуждениях цены, а также повышает продуктивность работы.
Недостатки варианта:
- Необходимость тщательного подбора специалиста в данной области, который будет иметь достаточное представление об изменяемой области. Это довольно сложное занятие для заказчика, особенно если он занимается этим впервые. В противном случае можно столкнуться с ошибками в расчетах, что может привести к увеличению сроков и стоимости работ.
- Данную работу можно будет доверить только крупным разработчикам, мелкие продавцы с такой работой просто не справятся. К тому же в команде таких разработчиков должны быть только специалисты высокого уровня. Это создает проблем как заказчикам, так и разработчикам, не каждая команда разработчиков может похвастаться высококвалифицированными кадрами в большом количестве.
Важная деталь в планировании: Даже если имеется точная оценка работ и у вас большой опыт по внедрению систем, все равно необходимо оставить запасные средства на реализацию проекта для непредвиденных ситуаций. Оптимальный вариант такой страховки — 30% от стоимости всего проекта. В противном случае, одна непредвиденная ситуация может привести к провалу весь проект лишь из-за того, что она не была предусмотрена заранее в бюджете проекта. В статье расходов ее можно обозначить как согласованное планированное отклонение стоимости проекта. Эти средства могут потребоваться при возникновении каких-то сложностей — организации обмена данными с программой, которая не поддерживает существующий API, доработка базовых справочников, сложности при переносе данных, реализация необходимых для работы функций, которые по той или иной причине не сумели предусмотреть заранее и т.д.
Таким образом, 30% бюджета будут припасены на крайний случай и выдаваться разработчику только при крайней необходимости. Если при внедрении проекта вы сможете обойтись без этой суммы, значит все просто замечательно. Ваш заказчик непременно обрадуется такому исходу дела, соответственно это еще один положительный отзыв о вашей работе. Затем последуют рекомендации друзьям и знакомым, а это уже новые заказы.
Но если все-таки возникла непредвиденная ситуация, которая требует обращения к этим деньгам, необходимо обоснованно и грамотно объяснить заказчику, зачем вам данная сумма денег. Подобная страховка бюджета крайне необходима, чтобы в дальнейшем избежать неприятностей.
Какие модули изменять в первую очередь?
С данным вопросом сталкиваются, пожалуй, все будущие пользователи систем ERP, так как ассортимент выбора огромный, возможностей масса, вот и растеряться здесь очень легко. Я все же, основываясь на своем опыте и практике других компаний, предложил бы начать с наиболее важных для работы модулей. А именно, со следующих:
- Финансы и взаиморасчеты. Не бюджетирование. Это совсем другая область, и не нужно ее приплетать сюда. Бюджетирование больше связно с планированием, поэтому его можно оставить на потом, когда первые модули уже будут работать в новой системе и приносить определенные результаты.
- Движение товарно-материальных ценностей (ТМЦ): хранение, реализация, поступление. Это тоже достаточно важный модуль в любом бизнесе, так как учет ТМЦ требует четкости и строгой последовательности. Обычно, перед тем как переносить остатки в новую программу, производят пересчет, и в новой программе уже вводятся остатки, полученные по факту пересчета. При этом важно правильно посчитать ТМЦ, чтобы потом не возникло проблем уже с новыми остатками.
- Бухгалтерский учет один из важнейших модулей в любой компании. Тем более, что любая бухгалтерия четко отслеживается законом, и в случае нарушений может быть предусмотрено суровое наказание. А потому бухгалтерский и налоговый учет обязательно должны внедряться в новую систему в первую очередь. Данный модуль следует изменять после пересчета ТМЦ, когда остатки сверены и перенесены в новую программу.
В некоторых компаниях меня критикуют за то, что я не уделяю должного внимания сегменту управления кадрами, мол, в компании может быть большая текучка, поэтому модуль HR тоже является важнейшим во внедрении новой системы. Я же отвечаю на это следующим образом. Конечно, кадры всегда имеют значение, но при внедрении такой сложной технологической системы, как ERP, отдел управления кадрами может поработать и в старой системе. На существовании и функционировании компании это не столь сильно отразится, как, например, если оставить в старой программе отдел финансов или движения ТМЦ.
Тоже самое касается и маркетинга с проектным отделом. Они также могут поработать в старой программе какое-то время. Главное, начать с модулей, которые напрямую связаны с работоспособностью компании и ее развитием. Для того, чтобы бизнес мог идти дальше с новой системой, ему нужен отлаженный модуль движения ТМЦ, бухгалтерского и налогового учета, и так, чтобы в этих отделах не было ошибок или недоработок.
Очень хочется верить, что данная статья о начале внедрения ERP, подходах к этому процессу и советы по планированию изменений будет полезной и для пользователей программного продукта, и для его разработчиков. Следующие мои статьи я посвящу своему личному опыту внедрения ERP, расскажу о своих ошибках, которые я допустил в свое время, а также обо всех важных моментах, на которые обязательно нужно обратить внимание при работе с ERP-системой, чтобы процесс ее внедрения прошел для вашего бизнеса максимально комфортно и эффективно.