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

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

Тема номера

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

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

www.sapland.ru

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

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

Тема номера:

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

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

ГЛАВНЫЙ РЕДАКТОР Александр Дублин adublin@sappro.ru

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

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

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

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

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

• Формировать scope проекта и регламент его выполнения так, чтобы минимизировать количество ABAP-разработок и неизбежных конфликтов между Заказчиком и Исполнителем при их согласовании. Обратная связь Мы очень надеемся, что Ваши комментарии к статьям и пожелания по содержанию последующих выпусков журнала помогут нам формировать актуальный контент в каждом выпуске. Пишите нам по электронной почте adublin@sappro.ru .

С уважением, Александр Дублин. Главный редактор «Сапёр»

2

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

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

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

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

Наступать на грабли - одна из наших национальных традиций. Об этом писал и великий классик. При внедрении ERP системы SAP стоимость каждого «наступления на грабли» имеет последствия куда более серьёзные, чем шишка на лбу. Цель этого специального выпуска журнала «Сапёр» - предупредить о граблях, ждущих вас на пути внедрения. Каким бы профессионалом вы ни были, не ждите удара по лбу и, как следствие, - потери времени и денег. Выпуск состоит из 10 разделов, каждый из которых посвящён каким-либо «граблям внедрения». В каждом разделе наряду с предупреждением о возможной «роковой ошибке» публикуются рекомендации профессионалов о приёмах и методах внедрения ERP системы SAP, которые позволят избежать этой ошибки. Мы классифицируем «грабли внедрения» по типам: 1) Грабли первого типа имеют следствием отсутствие улучшений бизнес-процессов, т.е. отсутствие отдачи от затрат на внедрение; 2) Грабли первого типа имеют следствием выход за временные и стоимостные рамки проекта и неоправданное увеличение стоимости продуктивной эксплуатации. Грабли внедрения первого типа • Грабли первые: «ERP – это софт» • Грабли вторые: «Привычка побеждает best practice» • Грабли третьи: «as - is» • Грабли четвертые: «Отчётность вчерашнего дня» Грабли внедрения второго типа • Грабли пятые: «Глоссарий нам не нужен» • Грабли шестые: «Члены команды внедрения» • Грабли седьмые: «Изоляция команды» • Грабли восьмые: «Безролевые игры» • Грабли девятые: «Что мне это даст» • Грабли десятые: «Тестирование» В выпуске активно цитируется материал книги Люк Галоппена и Зигфрида Кемса «Управление организационными изменениями при внедрении SAP», изданной в ООО «Эксперт РП». Авторами статей являются бизнес-аналитики Яков Басок и Александр Дублин. Обходите грабли или пользуйтесь ими по назначению!

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

1

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

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

Валерий Воробьёв

Дмитрий Халметов

Алексей Тоскин

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

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

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

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

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

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

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

Контактные данные: тел +7 495 646 75 58, доб 1024, e-mail: d.halmetov@id-mt.ru

Контактные данные: e-mail: Alexey.Toskin@t-systems.ru

Виктория Кривуля

Андрей Сергеев

Олег Точенюк

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

директор по консалтингу компании «Мигогрупп»

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

Работает с решениями SAР (в т.ч. и с SAPHR/ERP HCM) c 1999 года. Руководил проектами в компаниях: М-Видео, ВТБ24, Лебедянский. Эксперт в области проектного менеджмента и создания систем управления Контактные данные: тел +7 (495) 755-40-69, e-mail: info@migogroup.ru

2

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

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

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

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

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

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

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

Николай Цуканов руководитель группы управления проектами SAP-практики IBM GBS, PMP, MBA Занимается внедрением SAP с 2001 года. Успешно руководил более чем десятью проектами внедрения SAP в различных отраслях промышленности России и стран СНГ. Контактные данные: e-mail Nikolay.Tsukanov@ru.ibm.com

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

Дмитрий Григорович руководитель проектов в компании «СофтРейтинг Консалт» (Киев, Украина) Имеет успешный опыт руководства тремя проектами внедрения SAP. Контактные данные: e-mail dmytro.grygorovych@softrating. com.ua

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

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

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

3

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

ГРАБЛИ ПЕРВЫЕ:

ERP – ЭТО СОФТ «Если мы посмотрим внимательней на то, что отличает организации, успешно внедрившие SAP, от организаций, внедривших SAP неудачно, то мы увидим, что последние под целью внедрения ошибочно подразумевали установку программного обеспечения». Предупреждение

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

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

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

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

4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5

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

ГРАБЛИ ВТОРЫЕ:

ПРИВЫЧКА ПОБЕЖДАЕТ BEST PRACTICE Семь раз отмерь – один раз модифицируй. Народная мудрость

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

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

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

са между интеграцией SAP в организацию и интеграция организации в SAP». (Люк Галоппен, Зигфрид Кемс. «Управление организационными изменениями при внедрении SAP», издательство ООО «Эксперт РП», 2009 г.) Превратности метода Во всех проектах внедрения ERP-систем, в которых я участвовал, при определении объёма (scope) проекта ключевой проблемой обсуждения являлась проблема устранения несоответствия между возможностью ERP-системы и текущими бизнес-процессами. И, как правило, принималось волевое решение о «натягивании» ERP-системы на бизнес-процессы за счёт её модификации и «уродливых» настроек. Собственникам и топ-менеджерам казалось, что существующие бизнес-процессы оптимальны, а их изменение нецелесообразно. Консультант же не мог им противостоять, так как боялся потерять клиента. В случаях, когда принималось решение об изменении бизнес-процессов «под best practice от ERP», проект всегда наступал на грабли № 3, о которых я расскажу в следующей колонке.

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

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

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

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

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

Дмитрий Халметов

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

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

– А ты что же, слышал, как они поют?

– Да нет, мне вчера просто сосед напел... Мне всегда вспоминается этот анекдот, когда какой-то «сосед» делает вывод о неприменимости best practices для очередной компании. За время своей работы я твёрдо усвоил, что когда такой «сосед» хочет сказать, что SAP это не может, нужно просто найти эксперта, который в силах как минимум возразить этому «соседу».

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

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

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

Алексей Тоскин

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

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

Валерий Воробьёв

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

Дмитрий Григорович

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

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

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

7

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

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

Олег Точенюк

Николай Цуканов

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

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

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

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

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

= SAP freelance

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

8

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

CONSULTING GROUP

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

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

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

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

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

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

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

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

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

www.sapexperts.ru sapexperts@sapexperts.ru

+7 (812) 476-93-30

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

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

ГРАБЛИ ТРЕТЬИ:

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

Классическим началом проекта внедрения ERP системы (предпроект) является анализ (моделирование) текущих бизнес-процессов, так называемое построение модели «as-is» Предупреждение Классическим началом проекта внедрения ERP системы (предпроект) является анализ (моделирование) текущих бизнеспроцессов, так называемое построение модели «as-is». При этом: 1) Основное внимание уделяется проблемам важным в настоящий в момент. В результате получаются ложные опорные точки, так как эти проблемы, в случае изменения бизнес-процессов в соответствии с best practices, чаще всего теряют актуальность.

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

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

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

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

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

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

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

Дмитрий Халметов

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

Я хочу остановиться на том, кто и как должен делать описание «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 гораздо богаче.

Дмитрий Григорович

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

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

Алексей Тоскин

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

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

Валерий Воробьёв

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

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

Олег Точенюк

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

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

11

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

ГРАБЛИ четвертые:

ОТЧЕТНОСТЬ ВЧЕРАШНЕГО ДНЯ Не наливайте нового вина в старые меха. Книга

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

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

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

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

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

Причиной этого является: • и рядовые исполнители и топ-менеджеры предполагают даже после внедрения ERP системы работать «по старому»; • при продаже системы Заказчику обещана «отчётность на любой вкус». В результате все тратят усилия на удовлетворение требований «вчерашнего дня». Следует любой ценой уйти от определения будущей системы отчётности с позиции сложившийся практики.

12

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

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

Казус «отчётности вчерашнего дня» произошёл при внедрении ERP системы в производственной компании Z. Не обращая внимания на доводы внешних консультантов руководство приняло решение о разработке большого количества отчётов «вчерашнего дня». В результате бюджет проекта был увеличен на 10%. Через полгода эксплуатации выяснилось, что 40% отчетов «вчерашнего дня» не использовались ни разу, а 50% использовалось только первые два месяца эксплуатации системы.

грабли пятые

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

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

Виктория Кривуля

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

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

Дмитрий Григорович

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

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

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

Валерий Воробьёв

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

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

Олег Точенюк

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

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

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

13

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

ГРАБЛИ пятые:

ГЛОССАРИЙ НАМ НЕ НУЖЕН Помни почему «рухнул» проект «Вавилонская башня». Книга

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

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

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

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

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

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

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

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

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

Олег Точенюк

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

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

Дмитрий Григорович

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

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

Дмитрий Халметов

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

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

Валерий Воробьёв

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

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

Алексей Тоскин

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

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

15

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

ГРАБЛИ шестые:

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

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

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

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

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

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

Казус производителя мороженного «Z» При инициации проекта внедрения ERP системы Заказчик включил в команду: • сотрудников ИТ отдела, являющихся балластом (если бы не проект внедрения их пришлось бы уволить); • эффективных руководителей ключевых подразделений без снятия / снижения нагрузки. В результате, этап ознакомительного обучения дал очень плохие результаты, так как «трудные» ничего не поняли, а «эффективные» постоянно отвлекались на решение текущих задач. Это привело к

16

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

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

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

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

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

Валерий Воробьёв

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

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

Алексей Тоскин

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

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

Олег Точенюк

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

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

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

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

Все книги

SAP PRESS

только у нас

Discover SAP BusinessObjects

By Chris Dinkel, JC Raveneau, and Thierry Audas

Дмитрий Григорович

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

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

Applying Real-World BPM in an SAP Environment

By Ann Rosenberg, Mark von Rosing, Greg Chase, Rukhshaan Omar, and James Taylor

Next Generation ABAP Development (2nd Edition)

By Rich Heilman and Thomas Jung

www.sap-press.ru sap-press@sap-press.ru

+7 (812) 476-93-30

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

ГРАБЛИ седьмые:

ИЗОЛЯЦИЯ КОМАНДЫ «Книга жалоб у нас не ведётся» Девиз команды внедрения

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

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

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

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

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

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

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

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

Дмитрий Григорович

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

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

Валерий Воробьёв

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

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

9 35 64

A и версиями HAN ду двумя текущим Различия меж инструмент ки, используя ABAP разработ Как сократить ых данн я нени массового изме ии ункц й бизнес-ф с помощью ново запаса в пути Ввод значения l ирения 5 в пакете расш шаблонов Exce ских тель ение пользова Создание и хран в SAP ERP HCM тов для Ваших отче пе груп й ктно прое ми в ными личностя Управление слож ти еме ной эффективнос ами в SAP-сист организацион вления документ Оптимизация ти функций упра деся щью с помо м) рны ессным (рецепту проц ия влен Основы упра м в PP-PI производство SAP контрактами чественными оплаты Пользуйтесь коли товки вплоть до процесса заго для оптимизации

90

17

55

70

105

ия на стр. 2 ... обзор оглавлен стр 4 — 5 на ... содержание www .ExR P.ru

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

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

2 SAP Форума 201 Спецвыпуск для я 2012, Москва 23 ма

Москва

Олег Точенюк

Спецвыпуск

23 мая 2012,

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

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

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

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

ГРАБЛИ восьмые:

БЕЗРОЛЕВЫЕ ИГРЫ «Верным курсом идите, товарищи» Лозунг

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

20

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

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

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

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

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

Валерий Воробьёв

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

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

Алексей Тоскин

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

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

Андрей Сергеев Олег Точенюк

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

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

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

Дмитрий Григорович

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

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

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

21

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

ГРАБЛИ девятые:

ЧТО МНЕ ЭТО ДАСТ «Только гречневая каша сама себя хвалит» Пословица

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

c внедрением ERP системы и уровнем полезности новой системы для пользователя (WIIFM – what’s in it for me: что мне это даст). Превратности метода Возможны четыре ситуации «балансировки»: • Уровень WIIFM низкий, а требования к изменению поведения – серьёзные; пользователь воспринимает ситуацию так: «меня отвлекают от дела» (отвлекающие действия); • И уровень WIIFM, и требования к изменению поведения низки; пользователь вос-

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

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

22

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

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

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

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

Дмитрий Григорович

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

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

Валерий Воробьёв

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

Олег Точенюк

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

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

Тоскин Алексей

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

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

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

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

23

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

ГРАБЛИ десятые:

ТЕСТИРОВАНИЕ «Доверяй, но проверяй…» Пословица

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

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

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

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

24

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

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

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

Дмитрий Григорович

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

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

Алексей Тоскин

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

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

Олег Точенюк

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

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

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

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

Валерий Воробьёв

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

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

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

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

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