14‑15 ноября 2013 года
Бизнес-Школа «Сколково»
Докладчик: Максим Соложенцев, Архитектор бизнес-решений по обучению и поддержке пользователей
Все мы прекрасно понимаем, что просто внедрить SAP недостаточно: какая бы современная система у нас ни была и как бы качественно ее ни внедрили, все усилия могут разбиться об инертность конечных пользователей, недостаток знаний, низкую мотивацию к изучению новой системы и работе в ней. Рассмотрим, как справиться с этой ситуацией с помощью двух решений. Первое — SAP User Experience Management by Knoa: система онлайн-мониторинга опыта пользователей, которая позволяет определить, насколько эффективно работают пользователи и SAP-приложения. Второе решение — Workforce Performance Builder — оно позволяет выстроить процесс подготовки пользователей на проекте: подготовку материалов, рабочей проектной документации, то есть их поддержку в современном интерактивном виде.
SAP User Experience Management by Knoa
Эта система — некий «большой брат», который следит за тем, что происходит у нас в системе: что и где делают пользователи, сколько они работают, где и как ошибаются. Суть этого решения — поиск узких мест в людях, в процессах, в системах, в экранах. В результате вы сможете оптимизировать уже имеющиеся инсталляции, повысить отдачу от ваших сотрудников. В структуре решения — «агенты», которые устанавливаются на рабочие станции пользователей и следят в онлайн-режиме за тем, что они делают в системе, что они делают на работе – кофе пьют или транзакции выполняют. Соответственно, вся информация агрегируется на серверах, предоставляется в готовых отчетах Business Object — как видите, преднастроенные дашборды, преднастроенная аналитика позволяет нам анализировать, что у нас происходит в ландшафте, определять «очаги возгорания» — существующие либо потенциальные, и действовать проактивно.
Идея решения — в том, чтобы уйти от реактивного подхода поддержки пользователей к проактивному, чтобы IT работали не в режиме тушения пожаров работало, а на перспективу. Соответственно, данная информация позволяет определить узкие места, например, в компетенциях пользователей, разработать фокусные программы обучения, повысить эффективность их работы благодаря четкому пониманию, что именно вызывает у пользователей сложность в работе системы. Мы можем устранить системные ошибки, потому что мы их знаем, можем типизировать, структурировать и устранять их все в комплексе. Например, если мы знаем, что ошибка вывода на печать возникает не у одного пользователя, а у сотен, мы можем ее централизованно решить и разобраться - используется ли вообще функционал в системе. Это особенно важно для систем с большим количеством пользователей. Система собирает все данные с экрана, распознает все события, агрегирует их, обрабатывает, и также, в том числе по зашифрованному каналу, в зашифрованном виде, передает на сервер для обработки.
Очень часто, когда мы делаем Proof of Concept, многие заказчики удивлялись: почему за несколько недель тестирования даже в небольших группах, по 10-20 человек, обнаруживается до 1500 ошибок, и к том уже лишь 1-2 тикета попадают в Service Desk, остальное — как айсберг, скрыто. Как это выглядит? Cистема Knoa позволяет мониторить GUI Interface, портал, web-GUI, традиционный GUI-портал, CRM, Business Objects – практически все основные приложения. Соответственно, «агенты» системы собирают информацию, передают ее на центральные сервера UEM — отдельной системы, которая их агрегирует, обрабатывает и визуализирует на готовой аналитике.
Развернуть это решение в корпоративном IT-ландшафте достаточно просто, а технология нацелена на то, чтобы максимально автоматизировать и внедрение, и эксплуатацию. Агент – это MSI file, который удаленно разворачивается и представляет собой стандартные средства администрирования, встроенные в UEM — с их помощью управляются атрибуты агентов, версионность, обновление и так далее. Все делается с центрального администраторского пульта, без необходимости заходить на станции пользователей. То есть, в принципе, эту систему можно внедрить за полтора месяца — все зависит от объемов пользователей и, возможно, каких-то дополнительных потребностей. С точки зрения архитектуры это выглядит следующим образом: есть сервера UEM, которые разделены на операционные и аналитические – для оптимизации сайдинга пространства. В операционных серверах находятся «сырые» данные, которые мы получаем от агентов. Далее через специальный телепроцессинг они автоматически агрегируются и хранятся уже в аналитической базе данных. Плюс в том, что такой подход поможет оптимизировать дисковое пространство. При этом, когда мы анализируем отчетность, BI смотрит в обе базы данных, и подтягивает как «сырые» данные, так и агрегированные, чтобы мы могли получить и операционные показатели, и их изменение в течение года или двух лет.
У решения практически нет ограничений — поэтому в виде базы мы можем брать либо SQL, либо Oracle. Сценариев достаточно много, у каждой компании могут быть свои особенности использования системы.
Сценарии работы с Knoa
Во всем, что касается поддержки пользователей, цель UEM — упростить жизнь техподдержки, разгрузить ее от шквала повторяющихся событий.
Первый сценарий: за счет анализа и группировки сообщений об ошибках мы можем их устранять массово, а также определять — на каком шаге, в какой системе, у какого пользователя, при каких условиях эта ошибка возникла. Специалисты техподдержки сами, без участия пользователей, могут эти ошибки устранить. Такой сценарий сейчас использует «Северсталь»: на данный момент в их системе работает три тысячи пользователей, до конца года это число планируется увеличить до девяти тысяч. Буквально за полтора месяца эксплуатации благодаря отслеживанию удалось выявить огромное количество ошибок, о которых они ранее не знали. Сейчас идет приоретизация этих ошибок и, в соответствии с этим, готовятся «дельта-тренинги» — обучение сотрудников, позволяющее восполнить пробелы в уже имеющихся знаниях о системе. Определяются пробелы, решается, на чем сфокусировать дополнительную подготовку, а после проведения тренингов будет повторно измерено — какой эффект был получен.
Второй сценарий: все, что связано с поддержкой приложений. Здесь речь больше идет об управлении изменениями, когда мы с помощью нового функционала можем померить, насколько наши действия, скажем так, возымели успех или провал. Что есть процесс, по нашей терминологии? Это набор экранов, транзакций, каких-то действий, шагов, которые соответствуют какой-то задаче. Например, выставление счетов, формирование сбытового заказа, закупка — то есть сквозной процесс, который затрагивает один или несколько модулей, транзакций, экранов, ролей. Мы их все сводим в один функциональный процесс — например, сбыт, и смотрим на все показатели, связанные именно с этим процессом: степень активности пользователей, кто именно в нем работает, как меняется количество ошибок — системных и пользовательских. Все нацелено на то, чтобы это процесс шел быстрее, с меньшим количеством ошибок, с большей вовлеченностью пользователей. Такой сценарий использует, например, «Danone» и многие другие компании по всему миру, с учетом своей стратегии — например, если у компании глобальный процесс сбыта по всему миру, в различных странах, в различных городах, его можно отслеживать в рамках одной системы, в Knoa, и сравнивать показатели именно в рамках этого процесса глобально по всей корпорации. Там, где показатели наиболее оптимальные, где скорость выполнения этого процесса самая высокая, где количество ошибок минимальное, где количество ролей, вовлеченных в этот процесс, минимальное — можно рассматривать ведение процесса как эталонное и тиражировать его на другие сегменты корпорации. Таким образом, оптимизируются процессы и глобально распространяются лучшие практики.
Третий сценарий: обучение, когда мы с помощью UEM определяем, в каких областях подготовку персонала нужно усилить и какие дельта-тренинги (для сокращения разрыва между имеющимся уровнем знаний и реально необходимым) нужно провести. Такой сценарий планирует использовать МОЭСК: у них идет большая программа внедрения SAP, UEM им тоже продан, запуск этого проекта планируется в конце года. Один из аспектов — это связка IT с HR, так как отдел управления персоналом стремится к тому, чтобы оптимизировать затраты на обучение и при этом повысить квалификацию сотрудников, благодаря более целенаправленному, сфокусированному обучению.
Организация обучения
Как обычно организуется обучение пользователей? Например, есть портал, на котором выложены обучающие материалы, в соответствии с ролями сотрудников в организации и в проектах. Если приходит новый сотрудник, ему GRC назначаются права в соответствии с его ролью, даются все ссылки, пароли, логины, и его направляют на портал пользователя, где ему доступны материалы в соответствии с его ролью в организации, с правами доступа. Это все вводные инструкции, пакет документов в соответствии с его ролью в IT приложениях, вводные инструкции по внутренним процессам. Изучив эти материалы, пройдя, возможно, симуляционные тесты, он подтверждает, что все изучил и готов к работе в продуктивной системе. И тут может возникнуть проблема. С одной стороны, он обучен, сдал тесты — но это еще не означает, что он будет всегда работать правильно и без ошибок. Именно применение UEM позволило выявить и подтвердить, что равно люди ошибаются — даже опытные пользователи. Причем выявляются ошибки, о которых ранее не было известно, про которые не говорится в инструкциях и на тренингах. Стало быть, процесс отслеживания поведения пользователей должен быть постоянным, чтобы развивать сотрудников, повышать их квалификацию. Инструкции — это основа для того, чтобы человек вообще начал работать в системе корректно, а UEM — это инструмент, который помогает усовершенствовать навыки человека, чтобы он еще лучше работал, потому что он не может идеально работать сразу.
В случае, когда у организации глобальная структура, именно UEM выступает мерилом эффективности одного и того же процесса в разных странах. Тут используются, например, такие метрики, как response time (время отклика приложений), количество ошибок, количество времени, которое потрачено на выполнение процесса. Сравнивая эти и другие показатели, они выбирают лучшее — как раз это и есть управление изменениями.
Чтобы принять какое-то изменение, нужно понять, во-первых, что изменить, во-вторых — как это отразится на реальной деятельности. Нужно непредвзято оценить наши действия. Этот сценарий фокусного обучения используется в уже упоминавшихся проектах в «Северстали» и МОЭСК.
Четвертый сценарий: наиболее популярный, все, что касается оптимизации. Если мы рассматриваем глобально весь процесс и планируем его оптимизацию, мы можем выявить и детализировать — какие этапы процесса, какие экраны системы сложны для пользователей, на что они больше всего времени тратят, где больше всего ошибок совершается. Например, если речь идет об использовании клиентского кода — его необходимо поддерживать, к тому же от бизнеса могут поступать запросы на новый отчет или изменение функционала. Крупная нефтяная компания «Petrobras» (ЮАР) проводила миграцию SAP ERP с версии 4.0 на 6.0. За полгода, в течение которых они вели мониторинг новый системы, обнаружилось, что из десяти тысяч Z-транзакций, которые у них были, треть вообще не используется — следовательно, их можно было не переносить, не включать в процесс миграции. Следовательно, они существенно сэкономили на поддержке этого функционала. Это, кстати, один из рычагов воздействия на запросы от бизнес-пользователей: на основании данных из UEM можно отслеживать, насколько активно используются те доработки, которые внесены по просьбе бизнеса в систему, и избежать необоснованных кастомизаций.
Простым разбором логов, которых тысячи, мы не получим общей картины: их невозможно все обработать, визуализировать, проанализировать детально. Нет response time в чистом виде, нет корректного отображения активности пользователя, потому что выдается в логах только log-in и log-out, без реального времени работы в системе.
В России это решение представлено сравнительно недавно, около 2-х лет, но на рынке оно уже более 10 лет, это разработка американских партнеров SAP. За это время мы уже сделали ряд проектов — в «Северстали», в ТНК (до объединения с BP). Один из реализованных в проекте сценариев — применение UEM для поддержки удаленного центра обслуживания (ЕЦО). И это было неким рычагом воздействия — все сотрудники были на сдельной оплате труда, и система позволяла точно оценивать, кто сколько операций выполнил, какое количество документов сделали. В числе проектов - МОЭСК, «Сибур», «Метинвест».
За счет чего мы можем этот проект окупить? Вот реальные расчеты — понятно, что данные у каждого могут быть свои с точки зрения исходного состояния. Это происходит за счет повышения производительности пользователей, роста его компетенций, снижения затрат времени на обработку запросов в техподдержку, за счет наличия более детальной аналитики, отражения всех процессов в системе.
Мы экономим на времени обработки, на количестве обращений в поддержку, потому что можем комплексно решить одну большую проблему, а не разбираться с десятком обращений