Подготовка к проекту внедрения SAP HCM. Типовые фазы проекта внедрения SAP ERP Внедрение sap системы на предприятии

Добрый день, коллеги, читатели, друзья!

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

Введение

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

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

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

Заблуждение №1: Система работает за Вас или «синдром красной кнопки»

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

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

Был в моем опыте такой случай. Когда после получения практического опыта работы в системе уже после продуктивного старта, в компании сформировалась «оппозиционная коалиция». Эта группа людей специально копила весь негатив, все проколы консультантов, все ограничения функционала системы (а как вы понимаете, «функциональными ограничениями» системы SAP, по сравнению, например, с 1С, может быть невозможность удаления многих данных, невозможность «подчистки хвостов»). Ну так вот, наступил час «Х», когда весь этот ушат грязи вылился на команду внедрения, а также был предоставлен владельцу бизнеса, в качество основного аргумента в пользу возврата к старой учетной системе. В итоге все закончилось хорошо. И через какое-то время, люди, которые были самыми ярыми противниками новой системы, поняли, в чем ее преимущества, изменили свое мнение. НО, если бы менеджер проекта (с той или иной стороны) вовремя распознал бы проблему и провел необходимые разъяснения, таких протестов и скандалов можно было бы избежать.

Я упомянул про «синдром красной кнопки». Это своего рода байка среди коллег консультантов. Суть в том же. Каждый пользователь в той или иной степени хочет, чтобы количество рутинных операций, выполняемых им изо дня в день, каким-то фантастическим образом выполнялось в системе автоматически. Т.е. пользователь входит в систему, а интерфейс системы состоит из одной большой красной кнопки. Пользователь кликает на кнопку и система сама выполняет все необходимые операции. А пользователь в это время чай пьет. Консультантский фольклор трансформировал красную кнопку в красную педальку. Зачем педалька? Затем, что тогда жать можно ногой, и обе руки свободны. Одной – чай пьешь, другой – пасьянс раскладываешь. J Это все, конечно, шутки, но очень многие пользователи не устают удивляться, как система, внедренная за такие деньги, не может «немножко подумать за человека».

Заблуждение №2: Внедрение системы позволит «разгрузить» конечных пользователей

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

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

Хочу описать еще один пример из моего опыта. Я не знаю, конкретно к какому заблуждению его отнести, к №1 или к №2. Он (пример) в той или иной степени, касается обоих.

Для большой компании одной из ведущих мировых консалтинговых фирм была написана методика раздельного учета затрат. Требования к методике предъявлялись очень жесткие. Проработка положений методики и высокая степень детализации итоговых результатов распределения затрат для компании Заказчика была очень важна. Вторым этапом процесса разработки методики была ее автоматизация, которая производилась средствами системы SAP BW. Методика была автоматизирована, пользователи обучены, выполнена проверка качества работы со стороны фирмы разработчика методики. Заказчик был полностью удовлетворен результатами работы. Однако, для работы методики в SAP BW, необходим был достаточно большой объем исходной информации (как я уже писал, Заказчик уделял большое внимание детализации распределения затрат). Часть данных подгружалась из SAP ERP. Часть данных из прикладных систем. Часть заводилась вручную в MS Excel и с помощью специальных форматов подгружалась в BW. Для этой работы даже были выделены специальные люди. Вроде все было хорошо. Однако, через некоторое время компанию Заказчика стали покидать сотрудники, которые являлись главными идеологами использования разработанной методики, принимали участие в ее разработке и приемке. Это были люди, которые, помимо прочего, понимали важность подготовки необходимого объема первичной информации для получения корректных результатов финального распределения. Далее, по прошествии еще какого-то времени, от Заказчика были получены требования об упрощении степени детализации расчетов. Основная причина - слишком большой объем исходных данных, которые необходимо готовить. Упрощение было сделано в несколько итераций (опять же по мере поступления требований от Заказчика). И в итоге, от детальной аналитической модели остался «обрубок», который показывал какие-то обобщенные данные. О былой степени детализации говорить уже не приходилось.

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

Кстати, в начале статьи я упомянул ситуацию, когда Заказчик требует предоставить из системы какую-то модель (план, прогноз), основанный на имеющихся данных. Тоже очень распространенное заблуждение. Но я не буду отдельно выделять его. Это также касается заблуждений №1 и 2 (или где-то между ними). Суть в том, что руководство компании Заказчика или собственник бизнеса не совсем понимает различия между алгоритмом и исходными данными. Любая модель, прогноз, методика, наконец, состоят из:

А. Какого-то алгоритма, выраженного в четких и понятных математических/статистических формулах;

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

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

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

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

Заблуждение №3: Систему всегда можно «прогнуть» под бизнес

• не помню, где я это видел (где-то на просторах интернета), но фразу я запомнил очень хорошо: "…This has always been done like this and consultant should replicate it on SAP", - is the start of a big problem.

«…Это всегда работало таким образом, и задача консультанта продублировать процесс в системе SAP», - это начало большой проблемы.

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

В отличие от традиционных проектов по разработке программного обеспечения, внедрение SAP делится на три фазы: предвнедрение, внедрение и поствнедрение. Фаза предвнедрения рассматривается в главах 10 и 11. Внедрение с использованием методологии AcceleratedSAP (ASAP) рассматривается в главах с 12 по 17. Фаза поствнедрения обсуждается в главах 18 и 19.

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

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

Уровень 1 - Одно-двухдневные курсы, знакомство с технологией R/3 Уровень 2 - Трех-пятидневные курсы, обеспечивающие начальную специализацию в той или иной области Уровень 3 - Трех-пятидневные курсы, обеспечивающие глубокие познания в области, которая изучалась на уровне 2.

Курсы 10о уровня предназначены для тех, кто принимает принципиальные решения по системе, эти курсы рекомендуется проходить до начала проекта внедрения.

Компания SAP также предлагает Академические курсы для партнеров SAP, которые длятся 5-7 недель и включают в себя интенсивное изучение того или иного модуля (FI, СО, HR, SD, АВАР, Basis и т.д.). На этих курсах рассматриваются самые важные аспекты того или иного модуля, начиная от знакомства с модулем и заканчивая тщательным изучением конфигурации и работы на примере торговой компании. Выпускники этих курсов получают звание «Сертифицированный консультант» по тому или иному модулю. Раньше эти курсы были открыты только для консалтинговых партнеров SAP, сейчас они открыты для всех клиентов SAP.

Инсталляция SAP

Инсталляция SAP подразумевает установку базовой лицензии SAP и настройку пользовательского интерфейса. Это позволяет системе SAP осуществлять строгий контроль над качеством и эффективностью.

В недрение Малым и средним предприятиям компания SAP рекомендует ускоренную методологию внедрения AcceleratedSAP, которая состоит из пяти этапов:

Подготовка проекта

Составление схемы процессов предприятия

Реализация

Окончательная подготовка

Запуск и техподдержка.

Поствнедрение Фаза после внедрения подразумевает установку таких служб системы, как Справка SAP, систем восстановления потерянных данных и архивных систем. После внедрения базовых модулей можно приступать к внедрению других модулей - таких, как Хранилище данных SAP (BW), SAP Документооборот (Workflow) и т.д., а также ознакомиться системной архитектурой SAP, которая позволяет просто и быстро добавлять новые функции в систему.

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

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

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

Создание проектного офиса

Первая и, как правило, самая короткая фаза проекта. Очень часто её название вводит в «ступор» заказчика. Однажды, когда я имел честь работать во внутренней команде одного бравого металлургического предприятия, со стороны ТОП-менеджмента звучали довольно ехидные вопросы: «А что, на этом этапе они стулья расставлять будут?».

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

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

Обследование

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

Лучшей практикой считается подготовка описания бизнес-процессов в виде диаграмм в каком-либо CASE-продукте. Такую схему называют «Схема бизнес-процессов «Как есть (AS-IS)». Но, к сожалению, из-за дороговизны программных продуктов, а также низкой востребованностью со стороны заказчика, эта технология очень редко используется на проектах. А жаль, ведь её использование позволяет производить различные аналитические заключения о состоянии бизнес-процессов, производить оптимизацию и, самое главное, в дальнейшем при концептуальном проектировании и построении модели «Как должно быть» (TO-BE) позволяет производить сравнительный анализ, т.е. позволяет прогнозировать выгоды от внедрения ERP-системы. Результатом данной фазы также зачастую является уточненное техническое задание.

Концептуальное проектирование (модель TO-BE)

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

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

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

Реализация

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

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

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

Первоначальная поддержка

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

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

Моделирование бизнес-процессов: компания определяет желаемые или обязательные бизнес-процессы.

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

Анализ пробелов: компания оценивает расхождения или пробелы между стандартной функциональностью SAP и требованиями смоделированных процессов.

Окончательное определение рамок проекта внедрения SAP: компания определяет рамки внедрения SAP, то есть указывает, какие процессы будут внедрены вместе с SAP.

Настройка системы SAP: компания конфигурирует базовые параметры SAP с помощью Руководства по внедрению, чтобы удовлетворить ранее установленным требованиям (см. раздел «Конфигурация через Руководство по внедрению» в главе 12). Все настройки осуществляются в клиенте 001.

Тестирование настроенной системы SAP: функциональность сконфигурированной системы тестируется с использованием реальных данных.

Обнаруженные пробелы в функциональности могут устраняться с помощью следующих мер:

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

Программирования желаемой функциональности в ERP через пользовательские настройки.

Установки дополнительных программных продуктов других фирм, сертифицированных на совместимость с системой SAP через Программу дополнительного программного обеспечения SAP (CSP).

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

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

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

В системе SAP предусмотрена полноценная среда R/3 Business Engineer для помощи при внедрении SAP. При моделировании бизнес-процессов SAP возможно использовать любой из следующих инструментов: IDS Sheer ARIS, Microsoft VISIO, IntelliCorp LiveModel и Enterprise Charter. Они базируются на Справочной модели R/3 и обеспечивают прямой интерфейс для взаимодействия с функциональностью системы R/3. Это значительно облегчает понимание системы, потому что позволяет начинать специфические транзакции SAP прямо из среды моделирования: с другой стороны, предоставленные этими системами модели процессов, обеспечивают полноценный контекст той или иной транзакции SAP.

Справочная модель R/3 и упомянутые выше инструменты используют рекомендованную SAP технологию моделирования, которая называется «Управляемая событиями последовательность процессов» (Event-Driven Process Chain, ЕРС). В своей основе эта технология моделирует процессы как упорядоченный набор процедур, которые запускаются событиями внутри системы. Эти события могут происходить в базах данных (например, обновление) или на экране - когда, например, пользователь выбирает пункт меню или нажимает ссылку на Web-странице.

Процедурная модель SAP

Это традиционная модель внедрения SAP, она полностью интегрирована с системой SAP. Эта модель была представлена в 1995 году, одновременно с системой SAP R/3 3.0. Иногда использование Процедурной модели SAP ставится под вопрос: возникает ощущение, что эта модель устарела, и от нее надо отказаться в пользу AcceleratedSAP. Однако надо учитывать, что методология AcceleratedSAP в основном рассчитана на средние и малые предприятия, в то время как для крупных компаний Процедурная модель SAP остается лучшей методологией внедрения SAP. Так как в этой книге мы в основном рассматриваем внедрение SAP для средних и малых предприятий, здесь я представлю краткое описание Процедурной модели SAP, которая идеально подходит для компаний с доходами от 1,2 млрд. долларов.

На рис. 5.8 схематически представлена Процедурная модель SAP.

Рис. 5.8. Процедурная модель SAP.

Процедурная модель SAP состоит их четырех фаз:

1. Организационный и концептуальный дизайн

Подготовка проекта

Организация среды разработки

Обучение команды проекта

Определение функций и процессов

Определение интерфейсов и усовершенствований

Концептуальный дизайн и организация проверки качества.

2. Детальный дизайн и установка системы

Конфигурация основных параметров

Установка организационной структуры

Подготовка основных данных

Конфигурация процессов и функций

Внедрение интерфейсов и усовершенствований

Установка отчетности

Организация управления архивами данных

Последнее тестирование

Детальный дизайн и установка системы для проверки качества.

3. Подготовка к запуску

Создание пользовательской документации

Завершила очередной этап проекта по внедрению информационной управляющей системы SAP ERP на крупном машиностроительном заводе. Внедрение системы позволило предприятию наладить автоматизированный контроль всех процессов, дало возможность сократить себестоимость, повысить прибыль от продаж в 1,7 раза и пройти сертификацию ISO/TS 16949.

О заказчике

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

Проблемная ситуация

Проблема заключалась в номенклатуре - для производства детали требуется от 60 до 140 позиций инструмента. Предприятие выпускает до 50000 единиц техоснастки, на нем развернуто два производства - основное и инструментальное - работающие в три смены без выходных. Необходима была система, позволяющая проводить оперативный расчет потребностей для сбалансированной работы и выявлять реальную себестоимость изделий.
До внедрения решений АСАП Консалтинг предприятие прибегало к «лоскутной» автоматизации и платформам без централизованной базы данных, что приводило к проблемам:
противоречия баз и запаздывания данных на несколько дней;
появления информации «по факту», без возможности оперативной корректировки;
отсутствия данных о фактической себестоимости и затратах, невозможности предотвратить непроизводительные расходы.

Суть предложенного решения

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

Этапы внедрения

Специалисты АСАП Консалтинг ознакомились с имеющимися системами и, используя методологию компании и стандартные модули SAP, развернули пять основных модулей (плюс BC - техническая и системная поддержка проекта):
SD - управление сбытом;
MM - управление закупками и запасами;
CO - управление затратами и расчет себестоимости;
FI - РСБУ и НУ;
PP - планирование, учет и контроль производства.

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

Результаты и динамика

За полгода специалисты компании дополнили существующие мощности, внедрили обновленный функционал без остановки действующего. В процессе реализации развивались бизнес-процессы:
PM/TOPO - техобслуживание и ремонт оборудования;
WMS - управление складами;
BW - информационное хранилище;
FM - финансовый менеджмент;
CS - сервис клиентов;
НУ и МСФО.

В ходе проекта произошло разделение одного юрлица на группу компаний без остановок производства. Техобновление провели в сжатые сроки. Результатом интеграции SAP стали:
снижение норм расхода материалов на 10%;
экономия затрат - 2,5 млн. долларов или 510 тонн металла;
рост маржинального дохода на 20%, а прибыли от продаж - в 1,7 раза.
Кроме этого, на предприятии:
отлажен оперативный контроль дебиторской и кредиторской задолженностей по материалам и продукции основного производства;
в 6 раз сокращено время вывода новых изделий на рынок (за счет интеграции системы PDM T-Flex с решением SAP);
создана база данных для инструмента из 256000 позиций (с разузлованием);
налажено планирование «деталь-инструмент» с отбалансированной мощностью;
повысилось качество изделий, что дало возможность пройти сертификацию по стандарту ISO/TS 16949 для расширения сбытового портфеля за счет заказчиков с жесткими требованиями.

Результат

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