Комментарии по теме

«Игровой ролик: SAP для Retail»
Александр Дублин:
Суть ролика: если хотите спать в рабочее время, унижать подчиненных, то с решением от SAP вам это будет удобно. Сценарий ролика - продолжения истории: top-lap.livejournal.com/502664.html
«SAP CATS. Обзор ста­нда­ртно­го инстру­ме­нта учета рабочего времени»
Наталья Похилева:
Добрый день Сергей,   Очень полезная статья! Подскажите пожалуйста, а есть ли возможность стандартно забирать из HR в CO количество сотрудников ?   Спасибо,
«Прямой способ привязки кодов тра­нза­кций к опе­ра­ти­вным отчетам SAP Query»
Павел Васильев:
По двойному щелчку переходит в транзакцию, но открывает не тот номер по которому щелкали. т.е. просто открывает транзакцию.

Мероприятия

Академия передовых практик внедрения и поддержки SAP (2014-2015) Дата проведения: 9 октября 2014 г. Все мероприятия

Пример облачного решени: «HR goes cloud», то есть HR в облаке

Предыдущая Следующая

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

Пример облачного решени: «HR goes cloud», то есть HR в облаке

Докладчик: Андреас Каллен

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

У нас есть свое собственное on-premise решение, где реализованы и HR-процессы. Это решение, которое популярно в нашей компании и часто вызывает зависть других компаний, потому что не у всех оно есть. Но с другой стороны, важно понимать, как в рамках этого решения управлять глобальным и локальными процессами.

Например, локальные процессы — это выплаты пенсий в Германии. Но выплата зарплат — это международный процесс, потому что зарплату нужно платить сотрудникам во всем мире (это уж точно). Поэтому это выделяется в международную глобальную группу — это наше on-premise решение, собственное решение, ERP H7 система. Но теперь уже 2 года используется облачное решение, куда вынесены следующие международные процессы: управления сотрудниками или, как мы называем, талантами (Talent management) — это уже облачное решение, которое используется на международной основе.

Но мы по‑прежнему хотим модернизировать эту систему следующим образом. Мы хотим все больше расцентрализовать эти процессы и сделать их глобальными, всеобъемлющими и перенести их в облачные системы. Это и является концепцией программы «HR goes cloud» (HR в облаке).

Почему это важно? Когда представители бизнеса поставили передо мной эту задачу, я вспомнил поговорку «слона проще съесть по кусочкам». И спроектировал трехмерный куб, который помогает нам определить рамки и границы этого проекта. Этот трехмерный куб позволяет нам также дифференцировать эти куски программы по порядку и степени. Прежде всего, во внимание принимаются функции в HR. Второе измерение — географический фактор: 69 стран, в которых мы работаем. И есть еще одно измерение — юридические лица. Компания SAP время от времени приобретает компании, пополняет наше портфолио, и в наши ряды входят новые сотрудники, которых нужно интегрировать в мир SAP. Также появляются и новые юридические лица, которые не на 100 % интегрированы в SAP.

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

Проект делится на вертикальные функции и процессы, которые вы видите здесь — наиболее распространенные процессы выделены в программе отдельными проектами. Есть и cross-функции, которые отвечают за работу в разных бизнес-проектах. Например, они используются в Business Solutions Architect, в IT-Architect и в управлении бизнес-релизами (business release management). Это важно, потому что программа оценивается, и проекты оценивают на предмет их продуктивности достаточно часто.

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

Есть также еще один очень важный поток — управление изменениями и коммуникацией (change and communication management) в рамках организационного управления изменениями. Это очень важный фактор успеха любой программы.

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

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

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

Также для нас важна вовлеченность конечного пользователя. Как я уже говорил, у нас работают практически 70 тысяч сотрудников — нельзя включить в проект каждого из них, но можно задействовать представителей, проводников идей. Они дают отзывы по поводу usability, производительности и так далее, представляя интересы всех сотрудников и высказывая свои предложения от их лица.

Я считаю очень важным максимально упрощать коммуникацию. Мы используем Success Map — это наша внутренняя система факторов успеха, такая карта успеха. На ней каждому сотруднику видно, как он должен выстраивать свое развитие, если он хочет сделать карьеру в SAP. Это очень простой и наглядный инструмент коммуникации.

Из других HR-процессов, которые уже реализованы, отмечу управление компенсациями, человеческими ресурсами (Talent management), профилями сотрудников. Многие другие вещи также уже реализованы на глобальном уровне по общим для всей компании принципам, которые были описаны выше в этом трехмерном кубе. Некоторые из них были оттестированы и применены в отдельных странах, а часть из них — например, Talent management — работает по единым правилам для всех стран.

Итак, что же делает особенным управление программами в «облаке» по сравнению с программами on-premise. Существуют четыре аспекта:

1. управление изменениями,

2. реализация и тестирование,

3. подход,

4. стратегия и модель поддержки.

Управление изменениями в организации подразумевает определение границ и развертывание программ в этих границах. И управление изменениями тоже становится актуальным, если эти изменения происходят правильно, целенаправленно в отдельных странах. С помощью облака это становится актуальным повсеместно. Бизнес, будучи локальным, жил практически в идеальном мире: локальное on-premise решение позволяет выполнять практически любые требования бизнеса. Облачный подход подразумевает использование публичного облака, основанного на стандартных процессах. Они покрывают примерно 80 % требований, и в результате бизнес должен отказаться от 20 % специфических требований, а это не так‑то просто сделать.

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

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

Сроки проекта — это тоже важная вещь. Мы не используем глобальный подход Big Bang («Большой взрыв»), мы работаем с помощью нашего куба. Например, в Перу это решение может использоваться не сейчас, а лишь через 3 года — есть ли смысл сейчас обсуждать проект с перуанскими коллегами? Лучше с ними начинать разговаривать на эту тему через 2,5 года, когда для них эти перемены станут уже актуальными — и коммуникация на тему изменений тоже должна начинаться заблаговременно, чтобы они это вскорости вспомнили и не забыли об этом.

Я не говорю, что управление изменениями — это то, чем можно пренебречь в случае on-premise решений — это тоже очень важная вещь, но в случае облачных решений она становится еще важнее.

Второй из четырех пунктов. Обычно в on-premise решениях вы работаете в определенных заданных рамках и выполняете тестирование, пока он не будет завершено на 100 %. Но облачный подход не такой — он подразумевает большее количество итераций, изменений, он более гибкий.

И он, как правило, делится на три крупных шага. Прежде всего, 50 % реализуется в рамках этого проекта, 50 % тестируется. Например, конфигурацию, которая готова на 50 %, вы передаете бизнес-пользователям на тестирование, хотя она формально готова только наполовину. И делается это 3 раза: первая итерация — когда система готова на 50 %, вторая итерация –на 80 %, третья итерация — на 100 %. После каждой итерации вы должны получить подтверждение от бизнеса, «получите и распишитесь!»: «Спасибо вам, программный менеджер. Вы мне дали как раз то, что я ожидал. Я оттестировал, все готово». Или, наоборот: «Нет, не готово, не сделали, не принимаю». В любом случае это нужно сделать и внести коррективы, если необходимо.

Очень важно управлять зависимостями, так как в облаке важно использовать разные модули параллельно. Система компенсации, управление талантами, найм кадров, трудоустройство — все эти модули так или иначе зависят друг от друга и от HR-системы, и должны опираться друг на друга. Мы можем это делать в определенной последовательности — например, собрать целый портфель, управлять другими темами. Но надо помнить о том, что если есть зависимость, то она должна четко выдерживаться — это второй пункт.

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

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

Также очень важно учитывать то, что в облаке нельзя осуществить реверс-конфигурацию. Сначала лучше всего спланировать и оттестировать ее в «песочнице», возможно, вы поймете: «Оп! Такая система на 100 % не подпадает по требованию бизнеса, значит, нужно реверсировать конфигурацию». В этом случае вы просто удаляете, обновляете «песочницу», и все. Если бы вы это сделали в тестовой системе, то не смогли бы ее так быстро, как «песочницу», обновить. Так что лучше использовать подход в рамках «песочницы» для внесения изменений.

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

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

И последнее, но не менее важное, четвертое измерение — модель поддержки. Нужно сопровождать и поддерживать любое решение. И когда возникают проблемы, бизнес сообщает о них и хочет, чтобы проблемы исправили — это вполне понятно. Поскольку сейчас мы находимся в центре проекта по внедрению облачной системы, у нас используется не подход Big Bang, а гибридный подход. Отдельные страны используют on-premise-подход, а другие уже перешли к облачному подходу. Поэтому бизнес не знает, кому сообщать о проблеме, потому что бизнес не хочет решать, ограничена ли она рамками on-premise-решения или облачного решения. Бизнесу‑то, в принципе, неважно, где что находится — они не определяют это и не должны вносить никаких решений, вы решить должны это за них. И обычно в этом случае нужно создать систему ticket-ов, единую систему уведомлений о проблемах. И у вас должен быть налажен процесс, который определяет, относится этот процесс к облаку или нет, чтобы направить его соответствующим специалистам. Это чаще всего очень сложно сделать, так как в процессе, скорее всего, используется и та, и другая система: поскольку у нас ландшафт гибридный, задействован и облачный ландшафт, и локальный, on-premise. Но из‑за того, что плохой интерфейс между этими системами, процесс не работает, как надо — поэтому нужно создать сквозную ответственность, чтобы эти системы не рассматривались разрозненно. Процессы ведь должны работать, и неважно, где они расположены, on-premise или в облаке.

Если такой сквозной ответственности не будет, возникнет постоянный поток ticket-ов: заявка создается, специалисты по on-premise обрабатывают ее, убеждаются, что на их стороне все нормально, и возвращают этот ticket обратно. И эту игру в пинг-понг или отфутболивание мы должны прекратить — в конечном счете, найти людей, которые решат проблему, с которой пользователи обратились.

Итак, что у нас включается в ДНК облачного решения, что мы усвоили при облачном подходе?

1. Требуется использовать стандартную конфигурацию, которую развивать дополнительно нельзя — это стандартное требование.

2. Обязательно используется итеративный последовательный подход, итеративное проектирование. Не как в on-premise проектах — 6 месяцев ожидания, пока бизнес что‑то заметит, ни в коем случае! Это подход, который строится на создании прототипа, а потом его реализации.

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

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