Сапёр. Спецвыпуск 2012

Саперwww.sapland.ru

Интернет проектSAP Professional JournalРоссия

SAPLAND

Спецвыпуск июнь 2012Журнал для тех, кто внедряет SAP

КаК избежать«роКовых» ошибоКна проеКтахвнедрения SAP

Тема номера

2 Сапёр. Журнал для тех, кто внедряет SAP.

Тема номера: «Как избежать «роковых» ошибок на проектах внедрения SAP»

Тема номера:


Коротко об издании

Это первый выпуск журнала «Сапёр».

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

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

• Дать устойчивый научный подход к внедрению и эксплуатации ERP системы SAP как интегрированной информационной управляющей системы.

• Формировать scope проекта и регламент его выполнения так, чтобы минимизиро-вать количество ABAP-разработок и неизбежных конфликтов между Заказчиком и Исполнителем при их согласовании.

Обратная связь

Мы очень надеемся, что Ваши комментарии к статьям и пожелания по содержанию последующих выпусков журнала помогут нам формировать актуальный контент в каждом выпуске. Пишите нам по электронной почте [email protected] .

С уважением,Александр Дублин.

Главный редактор «Сапёр»

САПЁРИздательство ООО «Эксперт РП»Россия, 196608, Санкт-Петербург,г. Пушкин, ул. Ленинградская, дом 10.Тел./факс: +7 (812) 476-93-30Тел.: +7 (495) 646-80-29Веб-сайт журнала и другие предложе-ния на порталеwww.SAPLand.ruE-mail: [email protected]

АВТОРСКИЕ ПРАВАООО «Эксперт РП»обладает исключительными авторски-ми правами на материалы, опублико-ванные в журнале «Сапёр». Любое вос-произведение без предварительного письменного согласия издательства запрещено. Подробнее о компании на сайте http://www.exrp.ru/

ГЛАВНЫЙ РЕДАКТОРАлександр Дублин[email protected]

ТОРГОВЫЕ МАРКИSAP, SAP ERP и SAP NetWeaver яв-ляются зарегистрированными тор-говыми марками SAP AG. Все другие зарегистрированные торговые марки являются собственностью их вла-дельцев. Журнал «Сапёр» выпускается независимо от SAP AG и SAP CIS, не находится в собственности и не контр-олируется SAP AG и SAP CIS.

ОБ ОТВЕТСТВЕННОСТИНесмотря на тщательную подготовку всех материалов журнала «Сапёр», ре-дакция не несет никакой гражданской ответственности за его содержание. Редакция «Сапёр» ни при каких об-стоятельствах не принимает на себя ответственность за какой-либо ущерб или убытки, включая прямые, косвен-ные или последующие убытки, кото-рые могут быть понесены вследствие использования материалов журнала.

1Сапёр. Журнал для тех, кто внедряет SAP.

Спецвыпуск июнь 2012

предисловие

статьи этого номера комментировали

УЧЕНЫЙ СЫН (Басня)Сын приехал из города к отцу в деревню. Отец сказал: «Нынче покос, возьми грабли и пойдём, пособи мне». А сыну не хотелось работать, он и говорит: «Я учился наукам, а все мужицкие слова забыл; что такое грабли?» Только он пошёл по двору, наступил на грабли; они его ударили в лоб. Тогда он и вспомнил, что такое грабли, хватился за лоб и говорит: «И что за дурак тут грабли бросил!»

Цель этого специального выпуска журнала «Сапёр» - предупредить о граблях, ждущих вас на пути внедрения. Каким бы профессионалом вы ни были, не ждите удара по лбу и, как следствие, - потери времени и денег.Выпуск состоит из 10 разделов, каждый из которых посвящён каким-либо «граблям вне-дрения». В каждом разделе наряду с предупреждением о возможной «роковой ошибке» публикуются рекомендации профессионалов о приёмах и методах внедрения ERP си-стемы SAP, которые позволят избежать этой ошибки.

Мы классифицируем «грабли внедрения» по типам:1) Грабли первого типа имеют следствием отсутствие улучшений бизнес-процессов, т.е. отсутствие отдачи от затрат на внедрение;2) Грабли первого типа имеют следствием выход за временные и стоимостные рамки проекта и неоправданное увеличение стоимости продуктивной эксплуатации.

Грабли внедрения первого типа• Грабли первые: «ERP – это софт»• Грабли вторые: «Привычка побеждает best practice»• Грабли третьи: «as - is»• Грабли четвертые: «Отчётность вчерашнего дня»

Грабли внедрения второго типа• Грабли пятые: «Глоссарий нам не нужен»• Грабли шестые: «Члены команды внедрения»• Грабли седьмые: «Изоляция команды»• Грабли восьмые: «Безролевые игры»• Грабли девятые: «Что мне это даст»• Грабли десятые: «Тестирование»

В выпуске активно цитируется материал книги Люк Галоппена и Зигфрида Кемса «Управление организационными изменениями при внедрении SAP», изданной в ООО «Эксперт РП».

Авторами статей являются бизнес-аналитики Яков Басок и Александр Дублин.Обходите грабли или пользуйтесь ими по назначению!

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

Л.Н. Толстой



Дмитрий Халметов заместитель генерального директора «АйДи – Технологии управления»

Занимается внедрением SAP с 1997 года. Имеет большой опыт успешной работы в качестве консультанта по логистике. Актив-но участвует в построении в России эффек-тивной системы подготовки консультантов SAP, начиная с вуза включая все стадии профессионального мастерства.

Контактные данные:тел +7 495 646 75 58, доб 1024, e-mail: [email protected]

статьи этого номера комментировали

Валерий Воробьёв генеральный директор компании ООО «АСАП Консалтинг» (ASAP Consulting). Кандидат физико-математических наук

Занимается внедрением SAP с 1996 года. Имеет большой опыт успешной работы в качестве консультанта по модулю MM, в качестве менеджера проекта внедрения. Активно участвовал в формировании на-правления проектного менеджмента в САП СНГ, риск-менеджмента.

Контактные данные: www.asapcg.com

Виктория КривуляНачальник отдела сопровождения систе-мы управления затратами УК mySAP ПАО «Северный ГОК», Украина

Алексей Тоскин генеральный директор Т-Системс СиАйЭс

Более восемнадцати лет работал на рынке ERP-консалтинга, из них — более восьми лет возглавлял подразделение консалтин-га и обучения в компании SAP СНГ. Став в 2011 году первым лицом компании, Алек-сей Тоскин отвечает за реализацию дол-госрочной стратегии развития компании на рынке СНГ.

Контактные данные:e-mail: [email protected]

Олег Точенюкконсультант по SAP MM

Занимал должности консультанта по SAP ММ в различных компаниях, с 1997 года, занимался внедрением модулей FI-FM (контроль исполнения бюджета), Управ-ление материальными потоками (ММ), Управление складом СУС (WMS), выпол-нял работы по интеграции MM<->ТОРО, занимался разработками расширений си-стемы на языке ABAP,

Контактные данные:e-mail [email protected]

Андрей Сергеев директор по консалтингу компании «Миго-групп»

Работает с решениями SAР (в т.ч. и с SAPHR/ERP HCM) c 1999 года. Руководил проектами в компаниях: М-Видео, ВТБ-24, Лебедянский. Эксперт в области про-ектного менеджмента и создания систем управления

Контактные данные:тел +7 (495) 755-40-69,e-mail: [email protected]


Спецвыпуск июнь 2012 грабли первые

Николай Цукановруководитель группы управления проекта-ми SAP-практики IBM GBS, PMP, MBA

Занимается внедрением SAP с 2001 года. Успешно руководил более чем десятью проектами внедрения SAP в различных отраслях промышленности России и стран СНГ.

Контактные данные: e-mail [email protected]

отзывы о выпуске

Дмитрий Григоровичруководитель проектов в компании «Софт-Рейтинг Консалт» (Киев, Украина)

Имеет успешный опыт руководства тремя проектами внедрения SAP.

Контактные данные:e-mail [email protected]

Николай Цукановруководитель группы управления проектами SAP-практики IBM GBS, PMP, MBA

Безусловно, тема «граблей», в английском переводе «lessons learned», ставит вечно актуальные вопросы: «Кто виноват?» и «Что делать?». Актуальность поддерживается регулярно происходящими событиями, которых ну никак не должно было быть в силу широкой известности вопроса и поголовного просвещения участников в этой теме.Перечень из 10 «роковых ошибок» может быть многократно дополнен, перетасован по приоритетам, сконфигурирован, в конце концов, под нужного/текущего читателя.Вопрос, как мне кажется, не в этом.Я далёк от мысли, что специалисты, дошедшие до уровня принятия решений, приво-дящих к «роковым ошибкам», не в курсе истин, прописанных в первых главах любых учебников по менеджменту, или таких, о которых говорят лекторы практически сразу после знакомства с аудиторией.Думается, что проблема скрыта в последовательности «знать – понимать – использо-вать», между элементами которой порой располагаются громадные пропасти. Ну а для тех, кто добрался до финиша и уже готов «использовать», начинает работать принцип узкой «целесообразности».


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

Главное – не бояться!

2007.02.05-West Africa-Benin-CotonouЗнак «Не бойся!» Фото автора.



грабли первые:

ERP –ЭТО СОФТ

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

Казус компании «Х»

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

Предупреждение

«Если мы посмотрим внимательней на то, что отличает органи-зации, успешно внедрившие SAP, от организаций, внедривших SAP неудачно, то мы увидим, что последние под целью внедре-ния ошибочно подразумевали установку программного обеспе-чения». Даже если простое внедрение поддерживается некото-рыми изменениями в управленческой деятельности, этого ещё недостаточно, чтобы сделать внедрение SAP успешным. Орга-низации, выигрывающие от внедрения SAP, выигрывают именно потому, что рассматривают этот проект как фундаментальную предпринимательскую инициативу, которая трансформирует всё предприятие. Конечно, установка программного обеспечения является частью этого процесса, но лишь малой частью. Дру-гими словами, успешные организации понимают, что в основе проблемы лежат организационные, а не технические моменты». (Люк Галоппен, Зигфрид Кемс. «Управление организационными изменениями при внедрении SAP», издательство ООО «Эксперт РП», 2009 г.)

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

Целью большинства известных мне «изнутри» проектов было именно внедрение программного обеспечение, а не внедрение ERP-системы.

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

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

Доказательствами такого подхода к внедрению ERP-системы являются:• в команду проекта не включается менеджер по управлению

персоналом;• в состав работ не включены мероприятия по изменению орга-

низации, в том числе изменению системы мотивации.



комментарии экспертов:

грабли вторые


Довольно долго, работая консультантом, а потом руководителем проектов, я только и слышал о «зелёных клиентах» от консуль-тантов, которые участвовали в проектах ещё в середине 90-х. Причина этого за-ключается в том, что к началу 2000-х все «дремучие» специалисты уже либо столкну-лись с проблемами и прошли весь путь от их обнаружения до их решения, либо об-учились, а новые учебные программы уже выпускали подготовленных специалистов, которые и становились основными участ-никами проектов. Однако, перейдя в сферу продаж, я ощутил некоторый рецидив этого упрощённого «light» подхода к системам и к их внедрению. В чем причина? Дело в том, что «ломка» устаревшего сознания клиен-та, если она ещё сохранилась, происходит на presale стадии и должна закрепляться в содержании контракта. Но тут включается принцип узкой «целесообразности», когда либо продавцу надо продать здесь и сей-час, либо клиент ограничен бюджетом или желает получить малый, но успешный и бы-стрый результат.Участие в продаже продавца (заинтере-сованного в продаже) и потенциального руководителя проекта (заинтересованно-го в реализуемой архитектуре решения и проекта в целом), с одной стороны, и ру-ководителя со стороны клиента (будущего спонсора проекта), понимающего или, луч-ше, ответственного за стратегию компании – с другой, позволяют сконфигурировать продаваемое, реализуемое и полезное ре-шение. В нём будет место и ERP, и обнов-лённой компании.

Алексей Тоскин генеральный директор «Т-Системс СиАйЭс»

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

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


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


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

систему управления своим предприятием. Второй путь сложнее, так как потребует иногда существенных изменений в работе самой компании, но после его завершения генеральный директор вряд ли скажет, что он так и не понял, что же они там внедря-ли и куда потрачены деньги. Ведь без его участия второй вариант внедрения невоз-можен. Просто же софт можно внедрить на уровне максимум исполнительного дирек-тора или руководителя департамента IT.Чтобы избежать проблемы, что же мы в итоге внедряем, на этапе заключения со-глашения о внедрении хорошо бы понять причину, зачем компания Х решила вне-дрять систему Y. Варианты: все так делают; мы хотим увеличить капитализацию и т. д. практически сразу говорят о том, что со-бираются внедрять софт, и что тут победит – деньги или профессионализм, зависит от консалтинговой компании, но деньги, конечно, чаще сильнее.

Валерий Воробьёв генеральный директор компании ООО «АСАП Консалтинг» (ASAP Consulting)

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




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

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

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

са между интеграцией SAP в организацию и интеграция организации в SAP».(Люк Галоппен, Зигфрид Кемс. «Управле-ние организационными изменениями при внедрении SAP», издательство ООО «Эк-сперт РП», 2009 г.)


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

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

В случаях, когда принималось реше-ние об изменении бизнес-процессов «под best practice от ERP», проект всегда насту-пал на грабли № 3, о которых я расскажу в следующей колонке.

Типичные результаты подхода «натяги-вания системы на существующие биз-нес-процессы»:• расширение функциональности вне-

дрённой системы либо слишком затрат-но, либо вообще невозможно;

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

• внедрение ERP-системы не принесло существенных бизнес-преимуществ.

грабли вторые:

ПРИВЫЧКА ПОБЕЖДАЕТBEST PRACTICE

При внедрении ERP системы в одном из известных холдингов произошёл казус. Через полгода после доклада об успешном внедрении ERP системы холдинг был про-дан и новым руководителем был назначен иностранный менеджер. Этот менеджер по-требовал осуществления планирования в ERP системе. Оказалось, что после «такого» внедрения это просто невозможно. Какой же выход нашёл ИТ-директор?! Он посадил двух сотрудников, которые на-бивали в ERP систему план, составленный вручную!


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

Семь раз отмерь – один раз модифицируй.Народная мудрость




грабли третьи



Если удалось увернуться от граблей №1, то полдела сделано и осталось грамотно наладить управление проектом и работу с ключевыми бизнес-пользователями. Здесь конечно важно не пе-реусердствовать – клиент может просто психологически быть не готов к чересчур масштабным изменениям и если возможно, луч-ше стремиться к поэтапным изменениям, но конечно не в ущерб основополагающим принципам заложенным в SAP. Объяснять надо до последнего. Не бойтесь потерять клиента. Чем профессиональ-нее и аргументированнее ваша позиция, тем вероятнее, что вы всерьёз и надолго установите отношения с этим клиентом. Как один из способов борьбы за «best practice», можно предложить материальные и временные затраты на расширение объёма про-екта за счёт «специфики», относить на запрашивающего ключево-го пользователя / руководителя т.е на затраты соответствующего подразделения клиента.

Действительно, мы иногда слышим такие слова, как: «Наша ком-пания заплатила за ПО такие деньги, и неужели в SAP нет такой или иной возможности ?». Но, с другой стороны, в последнее время мы чаще от топ-менеджмента компаний слышим: «Вы не слушайте наших начальников отделов, они привыкли работать по старинке, а нам нужно все лучшее, что есть в SAP». Чтобы эти слова не оста-лись только словами, мы, как и в предыдущем случае устанавлива-ем искусственные барьеры в виде утверждений на Управляющих Советах всех изменений в стандарте. И это серьёзно снижает, если не исключает полностью желание «переделать» систему.


Дмитрий Халметов заместитель генерального директора «АйДи – Технологии управления»

Помните анекдот: – И чего это люди так Beatles нахваливают?! По мне так – полная ерунда, а не пение!– А ты что же, слышал, как они поют?– Да нет, мне вчера просто сосед напел...

Мне всегда вспоминается этот анекдот, когда какой-то «сосед» делает вывод о неприменимости best practices для очередной компании. За время своей работы я твёрдо усвоил, что когда такой «сосед» хочет сказать, что SAP это не может, нужно просто найти экспер-та, который в силах как минимум возразить этому «соседу».SAP прежде, чем это сделал, проанализировал схожую задачу тысячу раз. Вероятно, мы имеем дело с 1001-й совершенно новой постановкой, и такое возможно, но давайте признаемся, что все, что есть в best practices, не подходит, и настоящая постановка настолько новая, что теперь для строительства дома нужно изо-бретать кирпичи, принципиально новые по форме и составу. SAP – это «верх программного совершенства»? Конечно, нет. В программном обеспечении такой сложности это просто невозмож-но, но не нужно путать доработки новой отчётности с «небольшой» доработкой, которая просто исключает возможность использова-ния MRP. В первом случае система остаётся системой, а во втором система как целостный механизм просто перестаёт существовать. А что делать, если поле не чистое и система уже внедрена и ра-ботает? И понимаешь, что нужно было делать по-другому. Но если принципиальные вещи, такие, как возможность использования MRP, передача потребности и проверка доступности, использова-ние стандартных возможностей по выравниванию в финансах и т. д., избежали необратимых доработок, то все поправимо. Это просто и не просто одновременно – понять, что все, что нуж-но, в системе есть, осталось только это правильно применить. Но, как правило, именно слабые IT-знания заказчика вообще и SAP в частности являются движущей силой отказа от стандарта. В SAP – в best practices как в Mercedes – учтены все детали без-опасной езды: дело остаётся за малым – всем этим воспользо-ваться.

Такие грабли возникают всегда там, где отсутствует или неправиль-но поставлена внутренняя пропагандистская работа по внедрению ERP. Очевидно, что внедрение так или иначе видоизменит бизнес-процессы у Клиента. Это могут быть кардинальные реорганизации потоков информации, перераспределение ролей. Это могут быть

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





= SAP freelance

ООО «Эксперт РП»; +7 (812) 451-95-31, +7(495) 646-80-29, www.ExRP.ru

Формула вашего успеха

CONSULTINGGROUP


Эх, если бы только привычка, то это было бы не так страшно... В реальности этот самый best practice победил бухгалтера образца 1950–1991 года. Несмотря на то, что все рекламируют переход на международные стандарты учёта, по факту никто никуда не пере-ходил, зато SAP в настоящее время сделал как специфика страны: корреспонденцию счетов, оборотно-сальдовые ведомости и т. д. А зачем, чтобы показать по факту, что отдел дебета не обогнал отдел кредита, а в каких международных стандартах об этом написано? А поэтому не следует ожидать от консультантов, что они смогут быстро побороть привычку сотрудников компании делать что-то по старому: большинство людей не хочет изучать что-то новое, их устраивает подход: «Я так делал, до меня так делали, так что не ме-шайте работать».Эту привычку может только побороть неординарная ситуация из разряда: или вы делаете это по-новому, или меняете работу. Напри-мер, на одном из предприятий руководитель департамента планиро-вания закупок считал что и без SAP они неплохо вроде как работают, пока руководство холдинга не сказало на одном из совещаний, что планировать закупку в рамках 3 млрд, а по факту получить 2 млрд они сами могут и без департамента планирования закупки, а поэ-тому стоит задуматься о существовании данной структуры в рамках компании. И знаете, это оказалось таким стимулом в работе и изуче-нии системы SAP, что плоскость общения «у вас всё не так, непра-вильно, и не мешайте работать» сразу же перешла в плоскость «а как это сделать, и что для этого надо».

«Best practice». Часто употребляемый термин, доказывающий состоятельность подрядчика и гипнотизирующий заказчика. Как правило, этот принцип прописывается в контракте и все, дружно взявшись за руки, вступают на путь внедрения... .... Как-то лёжа в больнице, я подумал о разумности того, что пла-нируя операцию, я не обсуждал эту тему с хирургом в окровавлен-ном халате рядом с тележкой с хирургическими инструментами.....На одном из крупных проектов этот принцип был поставлен в осно-ву вырабатываемого решения. Но ползучая «контрреволюция» взя-ла таки верх и от «Best practice» в итоге осталось лишь «Именно так и случается на проектах....»В чем проблема? Узкая «Целесообразность». Средний менеджмент не хочет изменений, а руководитель проекта боится стать «пло-хим следователем». Как этого избежать? Следует помнить, что не решённая проблема сама по себе не исчезает и может проявиться в любое время и в другом качестве или в другом объёме. Не надо бояться конфликтов, тем более, если необходимо избежать од-ного, но летального. Процедура управления изменениями долж-на работать, даже если в отделы придётся сажать по хирургу со скальпелем и прочими инструментами. Ведь нигде в контракте не используется слово «безболезненный».

Оформляйте доступ к базам знаний SAP experts через российского распространителя ООО «Эксперт РП»

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

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

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

C GRC Expert улучшается поддержка и управление рисками и соответствием нормативным актам. Используйте наш передовой опыт для взаимодействия и осуществления управления рисками и соответствием нормативным актам; руководства для защиты систем SAP и данных; методы документирования и многое другое.

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

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

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

База данных SCM Expert ускоряет Ваше получение прибыли на инвестированный капитал (ROI) от SAP SCM и логистических систем SAP R/3, включая SAP APO, а таже прибыли с продаж и распространения, управления материальными потоками, системами оперативной логистики и системами планирования производства.

Используйте эту базу данных для управления SAP Solution Manager и связанными с ним вопросами, такими, как управление запросами на изменение, мониторинг решений и система отчетов, SAP-сервисы и поддержка, оптимизация технического обслуживания и ремонта, управление внедрением и развертыванием, управление обновлением (апгрейдом), маршрутные карты, тестирование и другие.

[email protected] +7 (812) 476-93-30




Классическим началом проекта внедре-ния ERP системы (предпроект) является анализ (моделирование) текущих бизнес-процессов, так называемое построение модели «as-is».

При этом:1) Основное внимание уделяется пробле-

мам важным в настоящий в момент. В результате получаются ложные опор-ные точки, так как эти проблемы, в случае изменения бизнес-процессов в соответствии с best practices, чаще всего теряют актуальность.

2) В отсутствие модели «to be» построе-ние модели бизнес-процессов «as is» осуществляется без целевого ориен-тира, в результате создаваемый до-кумент описывает аргументы, по ко-торым не стоит вносить изменения в существующие бизнес-процессы.

В результате построения модели «to be» и гэп-анализа с ранее созданной моде-лью «as is» формируется большой список

«расхождений». И начинается долгое об-суждение «что и как менять».

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


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

Изменения стандартной ERP системы должны быть приняты только топ-менед-жерами.

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

грабли третьи:

«AS IS»

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


Классическим началом проекта внедрения ERP системы (предпроект) является анализ (моделирование) текущих бизнес-процессов, так называемое построение модели «as-is»

Менять мир начинай с себя.Совет




грабли четвертые




Дмитрий Халметов заместитель генерального директора «АйДи – Технологии управления


Увы, третьи грабли невозможно обойти. Не пойдя к конечному поль-зователю, мы никогда не сможем провести предпроектное обсле-дование. Пойдя – мы «нахватаемся» тонкостей работы, причём в 90 процентах случаев мы никогда не узнаем истинных причин таких «as is», но никто не возьмёт на себя смелость их отмены или ре-организации. Действительно, только топ-менеджер может принять решение о ненаследовании в новую систему старых привычек, но тут всё зависит уже от его управленческой воли.

Переход от модели «как есть» к модели «как будет» всегда вызывает массу проблем, так как понятно, что будущие пользователи системы хотят всё оставить «как есть», но при этом получить новые возможно-сти из варианта «как будет». Так как пользователи не знают системы SAP, то и логических расхождений в своих требованиях между «как есть» и «как будет» они не видят. Задача консультанта на данном эта-пе – показать плюсы использования нового решения, фактически нужно понять, какой из плюсов для клиента важнее, и строить диалог на подчёркивании именно этого плюса в новой схеме работы.Например, на одном из проектов департамент продаж устраивала те-кущая информационная система, и функциональность SAP SD была им неинтересна. Для проекта же ERP в целом внедрение системы без SD смысла не имело. Давить же на то, что принято решение о внедрении SAP в компании в целом, смысла не имело, так как можно было бы получить скрытое противодействие всему проекту со стороны всего департамента продажи. В ходе встречи с руководством департамен-та продаж по некоторым обрывочным фразам было определено, что основной проблемой в продажах является контроль за исполнением проданных услуг. Поэтому уже на второй встрече упор был сделан на плюсах контроля за выполнением заказов техническими подразделе-ниями, а не на анализе и динамике продаж и т. д., после чего руковод-ство согласилось с нужностью внедрения SAP SD в своём подразде-лении и сказало, что будет оказывать всяческую поддержку проекту.

С моей точки зрения, As-Is в отдельный этап / документ выделять не нужно. В концептуальном проекте клиенту предлагается To-Be, а текущая модель используется точечно для аргументации пред-лагаемых изменений.

Я хочу остановиться на том, кто и как должен делать описание «as is».В одном из первых моих проектов была специально приглашена компания для описания существующих бизнес-процессов с мак-симально подробной детализацией. Посмотрев на результаты «as is», ни мы, ни консультанты от самой компании SAP не нашли по-чти ничего, что помогло бы внедренцам, и килограммы документов так и остались невостребованными.Специалисты, которые описывают «as is», и консультанты SAP ча-сто напоминают людей, про которых можно сказать: «Если у такого человека в руках молоток, то, за что бы он ни взялся, ему все будет казаться гвоздём». Так и проводились и сейчас нередко проводят-ся обследования «as is», когда у каждой из сторон свои молотки и свои гвозди. У одних – ARIS и стандартные вопросы, у других – одна модель реализации в SAP плюс ABAP на все случаи жизни. Я тогда специально занялся этим вопросом и изучил много разных документов от ASAP и ГОСТов до описания техник ведущих консал-тинговых компаний. Особенно меня интересовала тема описания «as is». Делать обследование «as is» нужно, держа в голове начальную гипотезу «to be». Но не нужно быть рабом этой гипотезы. Если факты не бьются с вашей гипотезой, то гипотезу нужно изменить или уточнить.Начальная гипотеза – это, по сути, модель «to be», которая сде-лана на основании опыта в решении схожих задач, плюс best practices и экспресс-анализ имеющейся информации. Но именно она делает осмысленным весь сбор и обработку информации «as is». И именно для её выработки должны быть привлечены самые опытные консультанты.Т. е. перед обследованием или в самом начале обследования «as is» должна быть сформирована начальная гипотеза «to be», вот только у архитектора SAP должен быть не один молоток. best practices гораздо богаче.

Мы достаточно успешно справляемся с этими «граблями». Нам удаётся убедить Заказчиков в успешности нашей методологии вне-дрения, в которой нет этапа «as is». На наших проектах внедрения, мы не проводим ни построения модели бизнес-процессов «as is», ни гэп-анализа «to-be» c «as-is». Мы сразу строим модель «to-be». Такой подход, вполне устраивает Заказчиков и позволяет сущест-венно сократить и время, и стоимость проекта.



грабли четвертые:

ОТЧЕТНОСТЬ ВЧЕРАШНЕГО ДНЯ

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

Не наливайте нового вина в старые меха.Книга


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

Причиной этого является:• и рядовые исполнители и топ-менедже-

ры предполагают даже после внедрения ERP системы работать «по старому»;

• при продаже системы Заказчику об-ещана «отчётность на любой вкус».

В результате все тратят усилия на удов-летворение требований «вчерашнего дня».

Следует любой ценой уйти от опре-деления будущей системы отчётности с позиции сложившийся практики.


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

Для решения проблемы «вчерашней отчётности» Люк Галоппен и Зигфрид Кемс рекомендуют:• привлекать к совещаниям по проекту

руководства среднего звена;• вести разработку отчётов «с нуля»;• разрабатывать отчёты с позиции буду-

щих бизнес-преимуществ и будущих способов работы.

Казус «отчётности вчерашнего дня» произошёл при внедрении ERP систе-мы в производственной компании Z.

Не обращая внимания на доводы внешних консультантов руководство приняло решение о разработке боль-шого количества отчётов «вчерашнего дня». В результате бюджет проекта был увеличен на 10%.

Через полгода эксплуатации выясни-лось, что 40% отчетов «вчерашнего дня» не использовались ни разу, а 50% использовалось только первые два месяца эксплуатации системы.





грабли пятые

Должна признаться, что когда прочитала материалы номера, испыта-ла массу чувств. Самым большим открытием было то, что в приведён-ных примерах легко узнавались люди, с которыми мы общались в процессе внедрения ERP системы и проблемы, с которыми при этом сталкивались.Наиболее актуальные грабли – отчётность вчерашнего дня. Я до сих пор вспоминаю, как после окончания института пришла работать в плановый отдел на предприятие. Начальник каждый день, как Зо-лушке давала массу работы, обещая, что когда я её закончу, то смогу сесть работать за компьютер. К концу определённого периода зада-ния закончились, и я уже радостно предвкушала интересную работу, когда начальница, крепко подумав, вытащила из шкафа тетрадь по фондоотдаче Актива, с датой последнего заполнения примерно де-сятью годами ранее. На мой изумлённый вопрос: «Зачем её запол-нять?!», она ответила – а вдруг кому-нибудь это понадобится!Сейчас, при анализе отчётности, используемой Активами, часто стал-киваюсь с тем, что ведётся много никому ненужных отчётов только потому, что «так раньше делали» и «вдруг кому-нибудь понадобится» (руководству среднего звена). Нужно именно с этим звеном прово-дить беседу. Наверное, нам немного повезло в том, что мы внедря-ем систему на Активах одного Холдинга. Поэтому, та отчётность, что интересует руководство, уже разработана. И именно среднему звену нужно объяснять, что незачем жить вчерашним днём.Мы признаем, что многое из этих отчётов можем реализовать в си-стеме. Но при этом говорим, что пока будем разрабатывать их, при-дётся пользоваться стандартными отчётами. А какие хорошие эти отчёты: можно и провалиться до первичного документа, и формат под себя настроить, и в EXCEL выгрузить… Часто именно время позволяет уйти от ненужных разработок.

С «ненужной» отчётностью вопрос очень деликатный. Вспомните фильм «Бездна»: ужас в глазах людей, которых переводили на ды-хание жидкостью. Человека в какой-то момент лишают привычного, жизненно необходимого в обмен на обещание «всё будет хорошо». То же самое произойдёт с любым управленцем среднего звена, ко-торого лишат привычных инструментов. Да, потом он приспособится. Да, потом он научится управлять на основе других отчётов. Но это будет потом! А сейчас руководитель проекта со стороны Исполните-ля получает вечного врага (и не одного, если управленец пригрозит уволиться).

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

Данные грабли вытекают из граблей 2 и 3, так как, с одной стороны, пользователи так привыкли, а с другой – при переходе к модели «как будет» только консультанты знают, что старые отчёты в таких раз-резах будут после старта системы неинформативными. Как решить данную проблему, когда одни привыкли, а другие не могут объя-снить, что первым это уже не надо? Можно попробовать сделать так: отчёты, которые являются внутренними, т. е. не являются требова-ниями внешних контролирующих органов, а приведённый в граблях отчёт «Запасы на дату» таким не является, вынести в раздел реали-зуемых после старта системы, т. е. такие отчёты не должны быть в разделе «критические», влияющие на старт системы. Таким образом, с одной стороны, соглашаемся с пользователями в нужности их ста-рых отчётов, а с другой – не стоим перед фактом их реализации на этапе внедрения. В итоге после старта системы через 2–3 месяца в списке отчётов останутся только те 10%, которые действительно нуж-ны пользователям, вот за их реализацию и можно приниматься.

Виктория КривуляНачальник отдела сопровождения системы управления затратами УК mySAP ПАО «Северный ГОК», Украина




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



грабли пятые:

ГЛОССАРИЙ НАМНЕ НУЖЕН

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

Помни почему «рухнул» проект «Вавилонская башня».Книга


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

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

сформированный глоссарий, применение которого сократит вероятность возник-новения последующих недоразумений». (Люк Галоппен, Зигфрид Кемс «Управле-ние организационными изменениями при внедрении SAP», издательство ООО «Эк-сперт РП», 2009г. )


Люк Галоппен, Зигфрид Кемс приводят в качестве примера неверного толкования термин «change management». Этот тер-мин, который означает «управление из-менениями самой компании», часто пони-мают с подменой понятия по следующим вариантам:

• «управление изменениями в рамках проекта» (внедрения ERP системы);

• «управление изменениями в програм-мном обеспечении» (в рамках проекта внедрения ERP системы);

• «изменение команды менеджеров».

Тема управления изменениями (change management) была отвергну-та руководством тайваньской компа-нии как неподлежащая обсуждению, потому что понималась им как «смена руководства».





грабли шестые





Дмитрий Халметов заместитель генерального директора «АйДи – Технологии управления

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

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

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

В настоящее время эти грабли встречаются все реже и реже. Глоссарии уже хорошо проработаны и наработаны достаточно большие их объёмы. Со знакомства с глоссарием, обзорными про-цессами в SAP всей проектной команды Заказчика, по сути, и на-чинается обучение / работа на проекте»

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

А теперь типичный глоссарий специалистов SAP в начале проекта: завод, места возникновения затрат, типы и виды материалов и т. д.И вот именно этот язык, как правило, мало понимают, как бизнес-заказчики, так и очень часто бизнес-консультанты. Вроде и не должны, так как на то есть специалисты SAP, чтобы, получив зада-чу в формулировках бизнеса, перевести её на язык SAP. Но мы же имеем дело не с заказным софтом, а с системой, и нужно найти ком-промисс между настройкой системы под бизнес, с одной стороны, и возможным изменением бизнеса под систему – с другой. Но это подразумевает итерационное совместное обсуждение. А на каком языке? С использованием каких терминов? На одном из проектов нас консультировала опытный руководитель проекта из Германии. После нескольких совещаний бизнеса с кон-сультантами SAP она мне сказала, как хорошо консультанты SAP по-нимают бизнес, а вот заказчики совсем не понимают SAP. Я тогда спросил: а как это происходит в Германии? Она ответила, что у неё на проектах бизнес-заказчики гораздо лучше понимают SAP, поэто-му все делается эффективнее. Но это достигается за счёт продуман-ности всего процесса образования, начиная с учебных заведений.Ситуация может быть еще хуже в случае, если в проекте добавля-ется язык ГОСТов. Нужно обязательно сопоставить термины ГОСТ и ASAP. Например, если предприятие навязывает ГОСТ, то фаза кон-цептуального проектирования может быть заменена на создание эскизного проекта. В любом случае, терминология и выработка общего языка является одной из основных задач, как в начале проекта, так на протяжении всего проектного цикла.



грабли шестые:

ЧЛЕНЫ КОМАНДЫ ВНЕДРЕНИЯ

Частой ошибкой является привлечение в команду проекта сотрудников из категории неэффективных или социально неуживчивых, желая убрать их «подальше от глаз»

«Кадры решают всё»Партийный лозунг


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

С другой стороны, «эффективные» сотрудники, направленные в команду, но никак не мотивированные, считают своё участие в проекте бесперспективной деятельностью.

В тоже время, будущее проекта, да и всей компании в целом зависит от работы команды внедрения ERP системы.


В результате описанного выше подхода к формированию ко-манды и её мотивированию компания окажется в ситуации: • в случае преобладания «трудных» сотрудников, запланирован-

ные бизнес - преимущества получены не будут, а сроки внедре-ния и бюджет проекта «выйдут за рамки»;

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

При инициации проекта внедрения ERP системы Заказчик включил в команду:• сотрудников ИТ отдела, являющихся балластом (если бы не

проект внедрения их пришлось бы уволить);• эффективных руководителей ключевых подразделений без

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

тому, что на этапе проектирования вместо совместной разработки эффективных решений консультанты занимались обучением ко-манды «азам».Часть эффективных сотрудников по причине перегрузок уволи-лась ещё до начала продуктивной эксплуатации ERP системы, а оставшаяся часть уволилась в течение полугода после внедрения. «Трудные» же сотрудники не смогли сопровождать работу систе-мы, и компании пришлось «покупать» на рынке дорогостоящих специалистов.

Казус производителя мороженного «Z»



грабли седьмые

Данные грабли являются из категории «internal only», т. е. все зависит только от руководства компании, которая решила внедрять систему. Если руководство реша-ет, что это важный элемент дальнейшего развития компании, то команда получается более-менее вменяемой и сильной, в про-тивном случае в неё действительно попада-ют по оценке сброса балласта из различных подразделений. Что можно в данной ситу-





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

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

Абсолютно поддерживаю всю важность формирования качественной проектной ко-манды со стороны Заказчика. С нашей точки зрения это один из важнейших факторов успеха проекта. Я бы даже сказал так, что если проект в результате стал успешен, зна-чит, как минимум, он был активно поддер-жан руководителем / спонсором, и у него была сильная замотивированная проектная команда»

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

Заходите на SAPLand.ru, чтобы воспользоватьсяпредложением

[email protected] +7 (812) 476-93-30

Applying Real-World BPM in an SAP EnvironmentBy Ann Rosenberg, Mark von Rosing,

Greg Chase, Rukhshaan Omar, and James Taylor

Discover SAP BusinessObjectsBy Chris Dinkel, JC Raveneau, and Thierry Audas

Next Generation ABAP Development (2nd Edition)By Rich Heilman and Thomas Jung

ВСЕ КНИГИ

SAP PRESS ТОЛЬКО У НАС



грабли седьмые:

ИЗОЛЯЦИЯ КОМАНДЫ

Большой ошибкой является изоляция команды проекта от остальной организации.

«Книга жалоб у нас не ведётся»Девиз команды внедрения


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

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

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

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


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

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

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

да проекта «закрылась» (в своей комнате) и стала делать то, что сочла правильным. Результаты «творчества» представлялись на утверждение только топ-менеджерам Заказчика, которые согла-совывали документы «не углубляясь в детали».Проект внедрения длится уже пятый год …

Казус приборостроительного завода «Y»


СТАТЬИ ИРЕКОМЕНДАЦИИПО РЕШЕНИЯМSAP НА РУССКОМЯЗЫКЕ

ww

w.ExR

P.ru

9 Различия между двумя текущими версиями HANA

17 Как сократить ABAP разработки, используя инструмент

массового изменения данных

35 Ввод значения запаса в пути с помощью новой бизнес-функции

в пакете расширения 5

55 Создание и хранение пользовательских шаблонов Excel

для Ваших отчетов в SAP ERP HCM

64 Управление сложными личностями в проектной группе

70 Оптимизация организационной эффективности

с помощью десяти функций управления документами в SAP-системе

... обзор оглавления на стр. 2

... содержание на стр 4 — 5

Спецвыпуск23 мая 2012, Москва

23 мая 2012, М

осква

Спецвыпуск для SAP Форума 2012

23 мая 2012, Москва

90 Основы управления процессным (рецептурным)

производством в PP-PI

105 Пользуйтесь количественными контрактами SAP

для оптимизации процесса заготовки вплоть до оплаты


грабли восьмые

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

Часто «изоляция» действительно зависит от квалификации, как сотрудников ко-манды внедрения, так и от квалификации консультантов, участвующих в проекте, при этом изоляция не всегда может быть видна в такой ярко выраженной форме. В казусе приведён явный пример изоляции, но может быть изоляция вида «грабли 6» совместно с «граблями 7». По внешнему виду это выглядит так. В одной компании консультанту дали сотрудника, с которым он должен работать как с ключевым биз-нес-пользователем, по факту через неко-торое время стало понятно, что данный сотрудник не ориентируется по всем во-просам, которые ему задают. Поэтому он начинает фантазировать на тему «Как это




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

работает в его компании». Консультант эти фантазии записывает, и они, совмес-тно довольные друг другом, что-то реали-зуют, при этом такая реализация нравится как консультанту, так и сотруднику. На этапе тестирования, когда привлекаются сотрудники, которые действительно зани-маются задачами, о которых ранее фанта-зировали консультант и сотрудник коман-ды внедрения, выясняется, что все не так и нужно переделывать.При этом на вопрос, почему не спросили у того, кто это делает, был получен ответ консультанта: «Мне сказали спрашивать только у сотрудника «А», и хотя я знаю, что это делает сотрудник «В», я не могу ослу-шаться команды руководства, с кем мне можно общаться». В результате все, что сделано, работает неправильно и начина-ется новый цикл по приведению системы в состояние, как действительно надо, а это время и, само собой, деньги. Как не попасть в такую ситуацию? Объясните проектной команде и внешним консуль-тантам, что, во-первых, всегда неплохо бы принимать решения, ориентируясь на слова тех, кто эту работу выполняет, во-вторых, это не всегда начальник, даже, точнее, это чаще всего не начальник, а его подчинённые, в-третьих, не бойтесь спрашивать, а если спросили и привле-кли человека к проблеме, то не забывайте держать его в курсе вопроса, по которому с ним говорили и... есть ещё куча других правил под общим названием «Как уметь идти на контакт с людьми».



грабли восьмые:

БЕЗРОЛЕВЫЕИГРЫ

«Самая распространённая ошибка при планировании обучения заключается в непосредственном связывании пользователей с курсами обучения»...

«Верным курсом идите, товарищи»Лозунг


«Самая распространённая ошибка при планировании обучения заключается в непосредственном связывании пользователей с курсами обучения; это прямой путь к тому, чтобы потерять из виду весь спектр способностей пользователя» (Люк Галоппен, Зигфрид Кемс).

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


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

В компании Z понимали обучение, как изучение руковод-ства пользователя нового программного обеспечения. Это привело к тому, что когда началась опытная эксплуатация, сотрудники вынуждены были работать круглые сутки, так как они знали, как «нажимать на кнопки», но не понима-ли, откуда какие данные получать и какие куда вводить. На решение этих проблем уходило 80% их рабочего времени и 90% рабочего времени консультантов.Как результат, в ERP системе скопился мусор и через месяц эксплуатации пришлось повторить продуктивный старт.

Казус компании «Z»




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

грабли девятые

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


Андрей Сергеев директор по консалтингу компании «Миго-групп»Олег Точенюк

консультант по SAP MM



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

Несомненно, что для эффективного обучения пользователей необходи-мо определить группы пользователей в соответствии с их вовлеченно-стью в бизнес-процессы предприятия. Но помимо этого необходимо в процессе обучения выделить так называемых «ключевых пользовате-лей». Проще всего это сделать, разбив обучение на два этапа:1) Обзор системы;2) Углублённое обучение функциональности.На этапе №1 мы определяем поль зователей, которые являются более обучаемыми по сравнению с остальными. Соответственно, для основной массы пользователей, этап № 2 дро-бится на отдельные функциональности (согласно их будущим ролям), а для ключевых пользователей этап № 2 включает в себя обучение всей функциональности.Также для повышения продуктивности обучения пользователей можно применить «метод совмещения», а именно: процесс обуче-ния совмещают с процессом тестирования системы. На данном эта-пе пользователи ещё не имеют «шаблонов» работы с системой, что положительно влияет на качество тестирования (в данном случае мы говорим о так называемом «UNIT-тестировании»).Процесс «совмещения» можно построить следующим образом: в первой половине дня занятий инструктор рассказывает теоретическую часть. Во второй половине дня пользователи приступают к практической ча-сти: осуществляют все шаги, написанные в тестовых сценариях.В результате такого подхода Компания приходит к началу продуктив-ной эксплуатации системы «во всеоружии». Пользователи будут вла-деть полной информацией по функциональности системы, получая теоретические и практические навыки работы в системе. А ключевые пользователи, обладая большим объёмом знаний, по сути, становятся руководителями групп и могут непосредственно влиять на функцио-нирование системы, и контролировать процесс продуктивной эксплу-атации. При совмещении обучения с тестированием пользователи не только повышают свои знания по работе в системе, но также учатся процес-сам взаимодействия по выполнению бизнес- процессов в системе, что является одним из нематериальных способов мотивации сотруд-ников к дальнейшему профессиональному росту.

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



грабли девятые:

ЧТО МНЕЭТО ДАСТ

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

«Только гречневая каша сама себя хвалит»Пословица


«Обычно пользователи переоценивают раза в три преимущества прежних систем, а руководители и разработчики в той же степени переоценивают преимущества, которые даёт внедрение новых систем. В результате этого непонимания возника-ет несоответствие между тем, что думает команда внедрения ERP системы о поже-ланиях пользователей, и тем, чего они дей-ствительно хотят» (Люк Галоппен, Зигфрид Кемс).

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

c внедрением ERP системы и уровнем по-лезности новой системы для пользователя (WIIFM – what’s in it for me: что мне это даст).


Возможны четыре ситуации «баланси-ровки»:• Уровень WIIFM низкий, а требования

к изменению поведения – серьёзные; пользователь воспринимает ситуацию так: «меня отвлекают от дела» (отвлека-ющие действия);

• И уровень WIIFM, и требования к измене-нию поведения низки; пользователь вос-

принимает ситуацию так: «легче согла-ситься, чем спорить» (простое решение);

• Уровень WIIFM высокий, а требования к изменению поведения – небольшие; пользователь воспринимает ситуацию так: «это то, что мне надо» (точное попа-дание);

• И уровень WIIFM, и требования к измене-нию поведения – высоки; пользователь воспринимает ситуацию так: «есть ради чего меняться» (терпение).

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

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

Казус «саПКа»




грабли десятые

По моему мнению, на данные грабли наступают, наступив на грабли «as is», когда вы уже должны были объяснить пользователям преи-мущества новых бизнес-процессов. Тогда вопроса, что это мне даст, уже теоретически не возникает. Если же в ходе концептуального проектирования этот вопрос просто продавливался, то вполне воз-можно к этапу запуска и работы встанут грабли «что мне это даст», когда пользователь не будет понимать, а что же он получил взамен работы по 12 часов. Что касается эффекта разъяснительной работы, то он отсутствует практически на всех проектах внедрения SAP, потому что у консуль-танта по большей части нет времени и это не его задача, собственно говоря, а у внутренней команды нет желания этим заниматься.




Тоскин АлексейГенеральный директор «Т-Системс СиАйЭс»

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

Тут, наверное, нет одинакового ответа для всех типов пользовате-лей. Самое главное, что высшее руководство Компании относилось к последним указанным уровням. А для работы со всеми остальны-ми необходимо использовать внутренний портал, заводские газеты, информационные листки, общие собрания, где объяснять выгоды предприятия, а значит, и сотрудников от использования SAP. Хуже, когда ряд топ-менеджеров реально находится в ситуации «отвлека-ющие действия», а демонстрирует другие ситуации, более позитив-ные, те, которые от него ожидают».

Очень тесно связаны с граблями №1-3. Можно избежать только через активную работу с ключевыми пользователями. Они должны: А- «ку-пить» для себя этот проект, что достигается их активной вовлечен-ностью и высокопрофессиональным общением и Б – «построить» своих людей пользуясь вашими мудрыми советами.



грабли десятые:

ТЕСТИРОВАНИЕ

Процесс тестирования является одним из тех, для которых справедлива инвектива: «лучше никогда поздно»

«Доверяй, но проверяй…»Пословица


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

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

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


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

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

Обычно в план проекта внедрения ERP-систем не закладывается время на донастройку системы по запросам конеч-ных пользователей по результатам тести-рования.

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

Основой причиной так называемых «усовершенствований» системы после продуктивного старта, существенно увеличивающих стоимость проекта, являются не «хотелки» пользователей и «точная» донастройка, а экономия на тестировании (см. выше).

Казус «mission impossible»



комменТарии эксперТов:

Тестирование – важный этап, но если проект разваривается нормально, то функциональ-ное тестирование приходит практически каждый день в процесс настройки систе-мы, а кросс-функциональное тестирование выполняется на периодической основе при




Алексей Тоскин Генеральный директор «Т-Системс СиАйЭс»

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

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

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

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

УНИКАЛЬНОЕ, НЕПРЕРЫВНО ПОПОЛНЯЕМОЕ ХРАНИЛИЩЕ ЗНАНИЙ И РЕШЕНИЙ В РАЗЛИЧНЫХ ОБЛАСТЯХ SAP.

Интернет проектSAP Professional Journal

Россия

саперЖурнал для тех, кто внедряет SAP

www.SAPlAnd.ruспецвыпуск июнь 2012

Documents

Сапёр. Спецвыпуск 2012