Как это понимать?
С 1 июля исчезает сертификация по HCM уровня Professional. Остается только облако и уровень Associate.
https://cdn3.training.sap.com/cdn/static-pdf/Valid_Cert_Exams_11_04_16.pdf/RU/EN
Профессиональные зарплатчики больше не нужны 🙂 Смотрите мой пост про накопленный опыт 😉
Кто-то из вас слышал, что я преподаю SAP, кто-то уже воспользовался, кто-то уже прошел и успешно работает в системе. На каждом занятии я даю практические примеры из своего опыта, чтобы ученик мог потренироваться на боевых задачах.
С другой стороны, я работаю в консалтинге и вижу, что многие люди не дотягивают до строчки в своем резюме. Для себя я почти сформулировал критерии оценки компетенций сотрудников. Предлагаю вам свое видение оценки для стажера. Стажер, это молодой и зеленый молодой человек или девушка, который увидели на HH.RU SAP и побежали в эту степь. Эту часть сегодня не обсуждаем.
Для меня стажер считается успешно прошедшим испытательный срок, если он может выполнить домашнее задание. Напомню, что мы говорим только про HR. И для стажера, я считаю, неважно, куда он собирается дальше: в базу или расширку — базу обязан знать. Раз обязан, то вот моя домашняя задачка.
Рано или поздно сложность разработки приложений, многообразие способов взаимодействия с пользователем, скорость изменения технологий приводят к необходимости все более тщательной проверки функционирования приложения. Внешне простое приложение на экране телефона часто содержит большое количество строк кода и логики, схем взаимодействия с внешней средой. Сегодня, во времена «облачной революции» в Сети, мы все чаще работаем с сервисами, которые предоставляют нам услуги. То же простое приложение может использовать не один сервис, а несколько и даже из разных мест. Например, заявка на отпуск может вызывать сервисы для получения персональной информации о сотруднике, о его руководителе, об остатке дней отпуска, о проверке возможности зарезервировать дни отпуска, — это все частные сервисы, выраженные функциями в системе SAP HCM, но функционирующими как сервисы.
Есть и другое приложение, которое отвечает за согласование заявки на отпуск. Разумно предположить, что это приложение использует сервис для получения персональной информации о сотруднике. Тот самый, что и заявка на отпуск. Мы реализовали сервис один раз, а уже окупили его разработку двумя потребителями сервиса. Два приложения получают информацию из одного сервиса, но однажды появляется третье приложение, которому необходимо расширенный набор данных о сотруднике. Например, вывести его пол или возраст. Простейшая задача про добавление поля в выгрузку данных может стать кошмаром в большой системе. Все дело в том, что приложения разрабатывались в различное время, на разных уровнях систем, разными людьми, возможно с разными подходами и технологиями. И это изменение структуры данных, которую отдает сервис, одним приложением может обработаться корректно, а второе перестанет работать.
С ростом инфраструктуры растет количество сервисов и потребителей. Любое мельчайшее изменение может остановить большую часть системы, что неприемлемо для современного бизнеса. Человек уже не в состоянии отследить все множество взаимосвязей и протестировать каждую связь, каждое звено в случае каждого изменения. На помощь приходят современные методики и технологии. Если мы можем алгоритмизировать процесс тестирования каждого конкретного случая, то такой процесс можно запрограммировать на автоматизированное тестирование компьютером. Компьютер может инициировать процесс, вставить необходимые данные, произвести вызовы сервисов, получить результат, и проверить его на совпадение с эталоном.
Другая часть приложения обычно отвечает за взаимодействие с пользователем. В приложении есть табличная форма заявок на отпуск, несколько кнопочек, включая кнопочку «Создать». На одном телефоне, где программист тестировал приложение, все работает отлично. На телефоне соседа табличка заезжает за поля экрана, кнопочку не видно. На компьютере кнопочка «Создать» не реагирует на нажатие, а у Ивана при нажатии на кнопку «Обновить» приложение завершает свою работу.
Такие ситуации, связанные с взаимодействием с пользователем, необходимо тестировать. Тестировать на различных платформах, разрешениях экранов, различных версиях браузеров и операционных систем. Такое многообразие вариантов потребует огромных ресурсов, которыми мало кто из разработчиков располагает. Для упрощения жизни тестировщиков появились серверы непрерывного тестирования, в задачу которых входит автоматизированное тестирование одного и того же приложения в различных средах. Такой сервер по заранее определенному сценарию запускает приложение в отдельной среде (нужная версия браузера, нужное разрешение, нужная операционная система), запускает все сценарии тестирования и записывает результаты в протокол. Разработчик уже работает с итоговым протоколом, где отражены ошибки, возникшие в конкретной среде. Локализация такой ошибки, исправление и перезапуск полного цикла тестирования экономит весомое количество времени, а значит и денег. Несомненно, что такое тестирование существенно повышает качество продукта, с которым будет работать конечный пользователь.
SAPUI5 основан на «китах Интернета» в лице HTML структуры, CSS разметки, JavaScript кода. Приложения, которые мы видим на экранах, созданы с помощью этих элементов статически или динамически. Когда мы нажимаем на кнопочку «Создать», то открывается новое окно. Мы заполняем его информацией и отправляем на сервер для создания записи в базе данных. Это уже целый процесс, где задействованы элементы экрана, коды для формирования запроса серверу и анализа результата. Раз все формализовано, то мы можем проверить работу процесса автоматизировано с помощью специальных инструментов.
Рассмотрим работу кнопки «Создать». По нажатию на кнопку происходит обращение к серверу (в общем случае) с запросом формы для окна создания новой записи. Сервер обрабатывает запрос и присылает необходимые поля, их оформление для визуализации на экране. Для пользователя это просто смена картинки, для автоматизированного теста это многоступенчатый процесс, который нужно проверить в нескольких ракурсах:
Выше приведен пример простейших тестов, которые должна выполнить система автоматизированного тестирования для проверки одной пользовательской операции «Создать». Если перемножить количество операций на вариативность сред для выполнения приложения и на возможные ракурсы, то мы понимаем, что без автоматизации не обойтись.
Предлагаю об этом нам и поговорить в следующих заметках.
Занимаешься САПом, занимаешься, а он все не угомонится.
Например, многие знают транзакцию «PUOC_33 — Межрасчетные выплаты: инструментальные средства».
Судя по бурной реакции на мои последние посты про наше настоящее и будущее, тема консалтинга становится животрепещущей. Предлагаю продолжить наши некрологи, но затронуть наиболее болезненное — расчет заработной платы. Скажу сразу, что я программист, а не мега-кто-то-там, поэтому рассуждаю со своей программистской точки зрения. Наш постоянный читатель и комментатор Василий неоднократно упоминал, что всё в облаке уже стало или станет в ближайшем будущем, даже заработная плата уже почти там, но с ограничениями в части программирования. Мне любопытно посмотреть на техническую организацию инфраструктуры SuccessFactors (SF далее), как они там это все устроили. Инстанции на каждого клиента создают? Манданты делают?
Что нас останавливает от перехода на аутсорсинг заработной платы в SAP? Менталитет и коммерческая тайна — раз. Сложное законодательство и зона ответственности — два-с. Недостаточная информатизация — три-с. Представим, что все эти условности решены и бизнес готов перейти в облако по любым причинам. У нас появляются задачи по организации независимого доступа бизнеса к своим данным, чтобы «ну никак» не пересекаться с другими предприятиями. Последняя мода на blockchain технологию может сыграть на руку. Второй задачей является управление требованиями со стороны бизнеса, которые необходимо реализовывать для соответствия целям бизнеса. Что особенно сложно, на мой взгляд, это управление множеством требований, которые могут противоречить друг другу в рамках одной информационной системы. Реализуется ли такое в SAP? Это не корпоративный шаблон, которым можно управлять в Solution Manager. Это полноценные независимые системы в одном сервисном поле. Похоже это те задачи, которые SAP пока не может придумать как решить, чтобы можно было предложить клиентам в рамках SF.
С другой стороны, существует множество провайдеров по расчету заработной платы, налогов вне SAP. Скорее всего это те же J2EE решения с общими настройками для всех бизнесов (какие-то общие и очевидные вещи) с возможностями доработки алгоритмов на языке программирования Java под конкретного заказчика. Думаю не секрет, что доработать частный алгоритм на голом программировании существенно проще, чем настроить систему SAP под него. Разумеется, что при этом должны быть четкие политики по ведению таких разработок у самого провайдера, системы контроля версий, системы тестирования. Где-то слышал, что сам SF написан на J2EE — на яве.
Про архитектуру высоконагруженных систем мы недавно общались. Если представить тетрадный лист в клеточку, где каждая клеточка это сервис, то получается вполне прозрачная картинка как может функционировать центр по расчету заработной платы, который будет построен на сервисной архитектуре. Например, есть какие-то специфические расчеты для конкретной отрасли, области (НПФ, налоги, льготы, социальные выплаты и пр.), и это все реализовано через сервис. Это ведет к тому, что на рынке появятся мелкие специализированные компании-сервисы, которые будут предоставлять такую услугу. На Западе это уже набирает обороты на HR рынке. Агрегаторы собирают страховые компании в пучок и предоставляют сервис по управлению страховыми планами. Сервис интегрируется в корпоративную среду и вуаля. Дальше начинает работать эффект объема и снижение цены на услугу.
Теперь представим, что такой сервис по расчету заработной платы скоро кто-нибудь реализует. Дальше вспомним последние покупки компании SAP. Не забудем, что SAP где-то в LinkedIn сказал, что развивать решение по заработной плате в Core особо не планирует. Вы поняли меня, да?
