Известно, что маркетинговые заявления вендоров порой серьезно расходятся с реальностью. Однако, принято считать, что авторитетные игроки рынка к подобной практике не прибегают. Однако, руководитель проекта внедрения SAP Business One в небольшой российской компании на личном опыте убедился, что «ничто человеческое не чуждо» и респектабельным компаниям.

Грани выживания

Несколько лет назад практически все мировые разработчики ERP-систем начали движение в сторону сегмента СМБ, который был объявлен чуть ли не самым перспективным и приоритетным. На рынок были представлены новые продукты, ориентированные на небольшие компании, с небольшими бюджетами на ИТ. Не стал исключением и российский рынок бизнес-приложений. В отечественной прессе появились убедительные статьи, информирующие российских бизнесменов о том, что в условиях ужесточающейся конкуренции (в том числе, при вступлении в ВТО) они не смогут выжить, если у них не будет современной, автоматизированной системы управленческого учета, планирования и контроля. Приводимые доводы были вполне убедительны. В результате руководство многих средних и малых предприятий России всерьез задумалось о переходе «на что-то лучшее, чем Excel и 1С». Наша компания также принадлежит к сегменту СМБ и в силу указанных выше факторов, приняла предложение одного из партнеров корпорации SAP на внедрение тогда нового для рынка продукта - SAP Business One (B1).

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

Вот - новый поворот

Компания SAP не стала исключение в мировой гонке за предприятиями СМБ и несколько лет назад заявила о «серьезных изменениях в продуктовом портфеле компании» и решении совершить «тотальный разворот в сторону рынка СМБ» и включить в свою продуктовую линейку решение, ориентированное на небольшие развивающиеся компании. Более того, было объявлено, что рынок решений для СМБ является одним из приоритетных для компании SAP. Управляющий директор SAP СНГ Алексей Шлыков тогда прокомментировал этот шаг так: «SAP вовремя распознала момент, когда рынок крупного бизнеса, на которые, прежде всего, были ориентированы бизнес-приложения компании, оказался близок к насыщению, и пришло время искать следующие рынки сбыта».

В результате в 2003 году на российский рынок была выведена локализованная версия SAP Business One - решения, принципиально отличающегося от того, чем SAP занималась раньше. Впрочем, SAP Business One не является разработкой немецкой компании: продукт был приобретен у израильских разработчиков. Любопытно, что выход SAP Business One не сопровождался масштабными рекламными кампаниями - все усилия по продвижению вылились в несколько информационных статей в прессе и серию региональных семинаров, которые для потенциальных клиентов организовывали партнеры SAP. Также было официально объявлено, что стоимость одного рабочего места «под ключ» (лицензии плюс консалтинг по внедрению) составит €2500–€3000, а продолжительность внедрения не будет превышать 8 недель. Кроме того, было известно, что продукт имеет одно существенное преимущество по сравнению с альтернативными предложениями – он настраивается, его не надо программировать, в отличие от решений «1С», и он уже содержит готовые бизнес-процессы.

Фактически, при прямой продаже нашей компании было заявлено следующее: «За 2 месяца мы внедрим продукт, и у вас заработает полноценная система управленческого учета». В том, что маркетинговая информация о продукте не соответствует его реальной сути, мы убедились уже на своем опыте позже. Пока же все звучало очень убедительно. Нас также впечатлили демо-ролики решения, презентованные партнером SAP (уважаемая, давно существующая компания в нашем регионе). Кроме того, был высказан самый веский аргумент - «вы под крылом надежного бренда SAP». И это развеяло все наши сомнения.

Суровая реальность

После трех месяцев внедрения стало понятно, что функциональность SAP Business One откровенно недостаточна для ведения даже небольшого (70 сотрудников) бизнеса в российских условиях. Почему мы этого не поняли раньше? Сложный вопрос.

Продукт, как нам сказали, на то и ориентирован на рынок СМБ, чтобы не втягивать компании в долгий этап обследования с последующим многотомным техническим заданием. В результате после этапа тестирования настроенного продукта мы столкнулись со списком «багов» на три с лишним листа, причем таких, без исправления которых переводить систему в рабочее состояние просто бессмысленно. Часть из них касалась именно ошибок в работе продукта, другая же касалась проблем недостаточности функционала решения. По составленному нами списку компания-внедренец была готова «доработать» около 30% требований, остальные же изменить без участия SAP было невозможно, потому что код продукта закрыт. Реализация тех «доработок», которые способен выполнить партнер своими силами, увеличила стоимость проекта сразу вдвое. Мотивировалось это тем, что «продукт нужно доработать в соответствие со спецификой бизнес-процессов». При этом, доработки действительно были необходимы, но только не под нашу «специфику», а просто, чтобы реализовать в продукте, в общем-то, стандартную модель ведения бизнеса. Никаких необычных требований с нашей стороны не предъявлялось.

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

Необходимо также отметить несколько серьезных недостатков SAP Business One, которые на первых презентациях неочевидны, а «всплывают» только в процессе:

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

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

Перечисленные «недоработки» вообще делают невозможным предоставление корректной информации о деятельности компании. При этом не вполне понятно, как в таком случае можно позиционировать SAP Business One в качестве системы управленческого учета. Розница, оптовая торговля и другой быстроразвивающийся бизнес с этой системой работать не сможет в силу ограничений ее производительности. Сохранение документа с 40-50 позициями приводит систему в ступор. Если таких документов будет хотя бы 200-300 в день, то все просто перестает работать.

Нам предложили «оптимизировать» бизнес-процессы нашей компании, что, по сути, является перестройкой ключевых для нас моментов и скорее смахивает на «втискивание» уже существующего отлаженного бизнеса в жесткие рамки решения. Если же мы не хотим перестраивать уже сложившуюся систему в нашей компании, нам предложили доработать решение. Причем речь здесь идет о расширении функционала решения и требует программирования с помощью так называемого пакета SDK (Software Development Kit).

Из разговора с компанией-внедренцем мы узнали, что SAP, вообще говоря, вынуждает партнеров самостоятельно дорабатывать функционал и писать так называемые add-ons (дополнительные компоненты). Эти компоненты можно также получить в готовом виде на коммерческой основе у других партнеров, которые уже реализовали данную функциональность. Например, для учета операций с основными средствами требуется купить соответствующий add-on, то же самое, если мы хотим вести учет фактических и плановых затрат, другой отдельный модуль предназначен для стыковки решения с системой банк-клиент. Кроме того, что стоимость проекта увеличивается, есть еще одна сторона: если мы покупаем add-on у другой компании, то нам надо либо привлекать их к внедрению за, опять-таки, дополнительные деньги, либо наш партнер-внедренец будет разбираться с этим самостоятельно, но тоже не бесплатно. Фактически, получается своеобразная «пирамида», которая разрастается тем сильнее, чем более широкая функциональность требуется предприятию.

Продать и забыть?

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

Сразу скажу, что ни один из указанных нами пунктов не был исправлен. Вместо этого была долгая переписка партнера с ответственными лицами SAP, которую, в конце концов, нам партнер даже показал. Большая часть ответов (вежливые, но короткие отписки с паузой в неделю) сводилась к тому, что о том или ином «баге» они прекрасно знают и активно над этим работают, так как не мы одни на это жалуемся. Практически все запрашиваемые нами моменты якобы исправлялись в новой версии SAP Business One. Которую мы ожидаем уже около полутора лет.

В результате, у нас сложилось мнение, что продемонстрированная «техническая поддержка» отражает общий подход вендора к бизнесу с предприятиями СМБ. Компания SAP в России ориентирована именно на крупных клиентов, потому что они имеют возможность инвестировать в проект неопределенное количество времени и средств. А вот СМБ бесконечно ждать не может и «кормить» консультантов SAP все это время - тоже. Более того, судя по «оперативности» и «содержательности» ответов на наши запросы, сложилось впечатление, что SAP заинтересована только в продаже лицензий, а конкретно по продукту ничего не делается. Примечателен и тот факт, как часто меняются в SAP люди, ответственные за клиентов по SAP Business One. Часть из них после старта проекта SAP для СМБ очень быстро переключилась с решения вопросов по продвижению SAP Business One на создание собственной карьеры внутри SAP, другая часть перешла в другие компании.

Арифметика маркетинга

Особый шарм маркетологам SAP-а придает заявление «SAP Business One - это система для управленческого учета». Повторюсь, какой может быть учет, если система не в состоянии предоставить истинную информацию о деятельности предприятия? Если система «со скрипом натягивается на бизнес» несчастными партнерами, которые просто вынуждены загонять компанию в рамки этого «решения»?

С самого начала запуска продукта SAP Business One на российский рынок было заявлено, что это решение для среднего и малого бизнеса. Так ли это на самом деле? Самой компанией SAP в СМИ была заявлена стоимость 1 рабочего места «под ключ» (то есть лицензия + внедрение) - около €2,5-€3 тыс. Кроме того, было объявлено (как преимущество продукта), что цена – конечная.

Для того чтобы действительно автоматизировать ключевые бизнес-процессы в небольшой компании, скажем со штатом 100-200 человек (финансы, продажи, склад, закупки), необходимо приобрести порядка 10-15 АРМ. То есть, рассчитывать надо на сумму порядка €30-€45 тыс. Как показывает практика, собственники российских небольших компаний, которые зарабатывают каждую свою копейку «потом и кровью», не так-то просто выплатят 30 тысяч евро/долларов за «софт». Тем более что налоговый учет и бухгалтерию в системе вести невозможно и, как минимум, «1С: Бухгалтерия» все равно будет нужна. Более того, если присмотреться к уже объявленным внедрениям, то видно, что полноценные проекты - редкое исключение и речь, как правило, идет о 3-5 лицензиях. Выводы напрашиваются сами собой.

Таким образом, по нашему опыту, SAP Business One может работать при условии существования не более 10 пользователей, в компании, где нет полноценного склада продукции, при этом может обрабатываться реально не более 2-3 заказов продукции в день. Возникает вопрос: «А нужна ли такая система небольшой развивающейся компании по две с лишним тысячи евро за рабочее место? Зачем, если на таком уровне достаточно использовать просто Excel?».

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

Если же говорить конкретно о российской действительности, то, может, причина в том, что последние 10 лет SAP здесь существовал в слишком комфортных условиях? Достаточно вспомнить даже официальные суммы инвестиций в ИТ наших промышленных монстров. И когда дело дошло до реальных действий, нормального развития и продвижения конкретного продукта, возможно, здесь потребовались навыки и компетенция, которые не требовались раньше? И проекты стали более прозрачными и теперь уже не так просто замолчать проблемы, как в масштабных внедрениях, где слишком много задействовано интересов, чтобы подвергнуть неприглядные результаты огласке.

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

Кстати, дополнительно об этой позиции SAP: на «круглом столе» 15 ноября 2006 года было официально объявлено о новых подходах к работе с партнерами, работающими с СМБ. SAP заявляет, что внедрение продуктов будет полностью осуществляться партнерами. А сам вендор «будет осуществлять общее руководство и размещение заказов». Что ж, позиция вполне логична, с точки зрения полного снятия с себя ответственности за результат проекта. То есть, с одной стороны, для российских руководителей за принятие решения о покупке ПО будет аргумент о солидности бренда разработчика, с другой же стороны, заказчики «один на один» останутся с партнером. А последний, в свою очередь, - «один на один» с продуктом. Если Вы еще сомневаетесь внедрять или не внедрять SAP Business One, постарайтесь поговорить напрямую с собственником компании, в которой якобы работает это решение. Попробуйте также задать менеджеру по продажам решения SAP Business One хотя бы часть из тех вопросов, что были подняты в этой статье.

Владлен Татарский

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

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

Введение

Не стану утверждать однозначно, но думаю, что практически каждый консультант/прожект менеджер/менеджер по изменениям, имеющий достаточный опыт внедрений 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 R/3: Руководство для менеджеров и инженеров Кале Вивек

Методологии внедрения SAP

Методологии внедрения SAP

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

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

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

Установка системной среды

Обучение конечных пользователей

Установка системной администрации

Проверка качества перед запуском системы.

4. Операции с системой

Техподдержка реальных операций

Организация Справки и помощи

Установка системных операций.

Методология AcceleratedSAP

AcceleratedSAP (ASAP) - это методология быстрого внедрения системы, представленная в 1996 году и предназначавшаяся в основном для американского рынка. Эта методология предусматривает большое разнообразие инструментов и утилит для облегчения процесса внедрения. Вот некоторые из них:

Ассистент внедрения

База данных вопросов и ответов (Question Answer Database, Q&Adb)

Тематическая база данных

Руководство

База знаний

Методология ASAP детально обсуждается в ч. IV этой книги.

Из книги Самоучитель UML автора Леоненков Александр

ГЛАВА 2 Исторический обзор развития методологии объектно-ориентированного анализа и проектирования сложных систем

Из книги Каждому проекту своя методология автора Коуберн Алистэр

Компоненты и объем методологии Под "методологией" я понимаю то, что написано в качестве первого толкования этого слова в Американском словаре Miriam-Webster: "ряд связанных между собой методов или техник". Оксфордский словарь толкует это слово только как "изучение методов". В

Из книги Модель зрелости процессов разработки программного обеспечения автора Паулк Марк

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

автора Реймонд Эрик Стивен

Проверка внедрения В разделе «Проверка внедрения» описываются шаги, позволяющие убедиться в том, что операции выполняются в соответствии с установленным процессом. В этот раздел обычно входят проверки и аудиты со стороны руководства и работы по обеспечению качества

Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен

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

Из книги Технологии программирования автора Камаев В А

Проверка внедрения Проверка 1. Регулярная проверка высшим руководством мероприятий по проведению программы обучения.Регулярные проверки проводятся высшим руководством для получения своевременной информации о производственном процессе и его понимания на

Из книги Внедрение SAP R/3: Руководство для менеджеров и инженеров автора Кале Вивек

Проверка внедрения Проверка 1. Регулярная проверка высшим руководством выполнения работ по управлению проектом.Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых процессов

Из книги Защита от хакеров корпоративных сетей автора Автор неизвестен

Проверка внедрения Проверка 1. Регулярная проверка высшим руководством выполнения мероприятий по инженерии разработки программного продукта.Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1

Из книги автора

Проверка внедрения Проверка 1. Регулярная проверка высшим руководством выполнения мероприятий по межгрупповой координации.Практики, связанные со стандартным содержанием проверок со стороны высшего руководства, содержатся в описании Проверки № 1 группы ключевых

Из книги автора

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

Из книги автора

Из книги автора

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

Из книги автора

12.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ Получив некоторое представление о необходимости рассмотрения методологии управления проектом, рассмотрим отдельные ее составляющие: предварительный анализ; четкая формулировка цели; составленные модели данных и словари;

Из книги автора

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

Из книги автора

Стратегия внедрения В этом разделе мы рассмотрим, какую стратегию должно освоить предприятие нового тысячелетия для проекта внедрения Системы ERP, «как товара на полках супермаркета».Внедрение модулей 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 важнейшую роль играет обучение команды внедрения и конечных пользователей.

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