Приветствую!

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

Постараюсь простыми словами донести суть методологии SAP ASAP , которая и по сей день является краеугольным камнем на пути к успешному внедрению системы SAP ERP на предприятиях.

Для начала немного предыстории.

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

В 1996 году компания SAP представила методологию AcceleratedSAP (ASAP) , нацеленную на значительное ускорение проектов внедрения. Методология ASAP позволила новым клиентам воспользоваться опытом и профессиональными знаниями, благодаря огромному числу внедрений по всем миру.

Что такое ASAP?

ASAP - методология быстрого внедрения и постоянной оптимизации - состоит из методологии Сетевого графика (Roadmap), который связан с такими инструментами, как IMG (mplementation Guide, "Руководство по внедрению"), причем ASAP задумывалась специально для средних и малых предприятий, которые не могут отводить на внедрение длительное время.

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

Методология Сетевого графика (Roadmap ) также включает в себя задачи по управлению изменениями и акселераторы, необходимые для управления изменениями на предприятии, вызванными внедрением SAP.

В этой статье я не буду углубляться в теорию, она сейчас не столь важна и интересна. Остановимся с вами на самом компоненте ASAP - Roadmap или Сетевым графиком , как его перевели в России.

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

Подготовка проекта (Project Preparation)

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

Определение целей и перспектив проекта,

Максимально точная оценка объема внедрения,

Определение стратегии внедрения,

Определение общего графика работ по проекту и последовательности внедрения системы,

Определение организационной структуры проекта и комитетов,

Распределение ресурсов.

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

Концептуальный проект (Business Blueprint)

Цель данной фазы - создание Концептуального проекта (Business Blueprint), который представляет собой подробно документированные технические и бизнес-требования заказчика к системе, за счет чего достигается полное понимание представления заказчика об организации бизнес-процессов в рамках системы SAP. На этапе концептуального проектирования определяется стратегия создания информационной системы, обеспечивающая быструю окупаемость инвестиций. Разработка концептуального проекта позволяет не только иметь программу действий при поэтапном внедрении, но и получить существенные экономические выгоды за счет усовершенствования существующей системы управления предприятием.

В рамках концептуального проектирования решаются следующие задачи:

Определение и анализ бизнес-процессов,

Формализация и документирование требований к будущей системе,

Детализация и утверждение окончательного объема проекта,

Выработка архитектуры системы и определение основных проектных решений,

Анализ и формирование стратегии обучения,

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

Реализация (Realization)

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

Тестирование системы на соответствие требованиям заказчика проводится в отдельной системе SAP для контроля качества и осуществляется в два этапа:

Функциональное тестирование

Интеграционное тестирование

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

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

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

Окончательная подготовка (Final Preparation)

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

Проводится нагрузочное тестирование , когда проверяется устойчивость системы к высоким нагрузкам на сервер. Также производится миграция данных из исторических систем компании-заказчика в систему SAP.

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

Запуск и поддержка (Go Live Suport)

Это фаза решения вопросов, связанных с запуском системы. Проводится проверка готовности к запуску, а также устраняются возможные проблемы.

Консультанты SAP осуществляют ежедневную поддержку пользователей, а также устраняют ранее скрытые ошибки и несоответствия в системе.

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

Оптимизация (Run SAP)

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

Оптимизация документации решения

Оптимизация реализации решения

Оптимизация шаблона

Оптимизация тест управления

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

Вот вкратце таковы все этапы внедрения SAP ERP на предприятия. Надеюсь, теперь вы понимаете, почему методология ASAP так важна при внедрении.

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

До связи,

Никита.

Было полезно? Ставьте лайк и читайте прямо сейчас следующую порцию полезной информации:

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

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

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

Немного о компании и продукте

В 1972 году в Германии пятью бывшими сотрудниками корпорации IBM была основана компания SAP (Системный Анализ и Разработка программ). Их целью было разработать стандартное программное обеспечение, объединяющее все бизнес процессы на предприятии в реальном времени.

Спустя 25 лет фирма стала несомненным лидером в нише автоматизации по планированию ресурсами предприятия (Enterprise Resource Planning – ERP). Сегодня это корпорация, имеющая филиалы и дочерние офисы во всех промышленно развитых странах.

В России история компании насчитывает уже 20 лет. Первый офис этой международной корпорации был открыт в Москве еще в 1992 году. Сегодня офисы работают в Санкт-Петербурге, Новосибирске, Екатеринбурге, Ростове-на-Дону; русский язык стал одним из основных языков локализации программных продуктов, более 1000 сотрудников россиян занимается внедрением основных программных решений.

Что это такое

SAP ERP – информационная корпоративная система, основанная на методологии ERP (планирования ресурсами предприятия) и направленная на достижение оптимальности бизнес-процесса.

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

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

SAP ERP — позволяет руководителю видеть процесс производства в реальном времени, при этом, не вникая в суть проблем, правильно оценивать динамику движения процессов на предприятии.

Видео: SAP ERP - введение

Основные модули программы

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

Все ключевые направления деятельности:

• оперативное управление производством;
• участки учета (бухгалтерия, финансы, склады, транспорт);
• планирование и контроль;
• кадры.

В итоге: наблюдается не только широкая функциональность, но и полная интеграция между модулями.

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

Дополнения к пакету

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

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

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

Примером может служить модуль RCM – это электронный документооборот. По-другому его называют модулем управления корпоративным контентом. Удобный элемент работы с документацией.

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

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

Процесс запуска в работу проекта можно условно разбить на следующие этапы:

• создание документации об управлении проектом (приказ, устав, календарный план);
• обследование объекта автоматизации;
• концептуальное проектирование. (создание модели управления предприятием);
• поэтапная реализация;
• поддержка и обучение пользователей.

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

Преимущества внедрения пакета ERP

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

И все же…Внедрение программ такого класса позволяет удалить самые «болевые точки» в работе предприятий. К ним относится «прозрачность» производства и неэффективность. Руководителю организации чтобы понять, «где болит», нужно изучить «симптомы». Вот это и помогает сделать такая система .

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

Что такое SAP R3: описание

На российском рынке наибольшую популярность приобретает программа SAP R3. Что это такое? Это пакет бизнес-приложений, поддерживающий в последней 4.0 версии полный выход в Интернет, доступный для малого и среднего бизнеса по ценовым характеристикам. Пакет позволяет осуществлять стандартизацию внутренних бизнес-процессов, повышает эффективность работы предприятия.

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

Внедрение таких систем с 1995 года позволяет констатировать, что сегодня они работают более чем в 40 странах. В России она очень широко используется для формирования заявок, проведения поставок.

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

По статистическим опросам, уже 76% предпринимателей голосует за то, что IT – их помощник в бизнесе. Процесс конкуренции заставляет руководителей приходить к правильному решению: заняться внедрением проектов SAP.

Внедрение SAP с нуля

Внедрение новых или совершенствование действующих информационных систем управления на базе программных продуктов компании SAP SE выполняются компанией СКАЙРАЙЗ в форме проектов по проверенным методологиям ASAP, ASAP Focus, PMBOK.

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

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

Системно организованный проект проходит следующие стадии:

• Инициирование проекта
• Концептуальное проектирование (разработка проектных решений)
• Техническая реализация проектных решений
• Тестирование
• Обучение пользователей
• Подготовка в запуску ОПЭ
• Запуск системы в продуктивную эксплуатацию и его сопровождение

Компания СКАЙРАЙЗ берёт на себя управление содержанием работ, графиками и сроками, ресурсами и качеством результатов проекта. При этом Управляющий совет и участники проектной группы со стороны Заказчика всегда имеют возможность контролировать и быть вовлеченными в решения проекта.

Большое значение компания СКАЙРАЙЗ придаёт имеющемуся отраслевому опыту создания информационных систем и моделям лучших отраслевых практик (SAP Best Practices) (см. также — отраслевые решения).

В каких случаях требуется внедрение SAP с нуля

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

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

Ролл аут SAP корпоративного шаблона

На основании разработанных потребностей в автоматизации для её ускорения может использоваться уже проработанное решение – Шаблон (Template).

Корпоративный шаблон обычно разрабатывается для крупного международного холдинга, когда требуется:
• Унифицировать бизнес
• Учесть локальные требования
• Объединить данные в едином информационном пространстве

Также возможно использование отраслевого шаблона из набора отраслевых решений (SAP Best Practices).

Расширение функциональности SAP продуктивной системы

Расширение функциональности продуктивной системы

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

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

Расширение функциональности обычно производится при помощи методологии внедрения ASAP.

Разработка пользовательской функциональности

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

1. Инструменты сканирования штрих-кодов при помощи мобильных устройств — ссылка
2. Система управления коммерческим оборудованием —
   ссылка
3. Система управления обеспечением средствами индивидуальной защиты — ссылка

Переход на SAP HANA

Переход на SAP HANA (англ. High-Performance Analytic Appliance) осуществляется в соответствии с методологией SAP Activate.
1. Сначала описывается весь перечень используемых бизнес процессов
2. Описывается весь перечень используемых справочников
3. Описывается весь перечень используемых интерфейсов
4. На приобретенное оборудование (в случае On Premise версии) устанавливается ПО SAP HANA.
5. Производятся пользовательские доработки функционала
6. Производится миграция справочников и исторических данных из старой системы в новую при помощи специальных инструментов
7. Производится тестирование работы функционала в новой системе.
8. Производится активация интерфейсов
9. Производится переход на новую платформу