Меню

Направление на Солнце. Создание успешной сети ключевых пользователей*

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

The Super User (R)Evolution. Unleashing the Collaborative Forces Already in Your Enterprise

Ginger Luttrell & Michael Doane

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

*Оригинал (англ.): Настольная книга ключевого пользователя. Джинджер Латтрелл, Майкл Доан. Enterprise Alliance Press. Глава 6. 2017, с. 121–144. The Super User (R)Evolution. Unleashing the Collaborative Forces Already in Your Enterprise. Ginger Luttrell & Michael Doane

*Направление на Солнце. Создание успешной сети ключевых пользователей // SAP Professional Journal Россия, март–апрель, №2 (79), стр. 4–18. @ 2020, Джинджер Латтрелл, Майкл Доан.

Начнём с известной шутки:

Нам сказали: «На Солнце нельзя высадиться, идиоты! Вы сгорите!»

На что мы ответили: «Мы понимаем, мы ж не дураки. Мы сделаем это ночью!»

«Запуск сети ключевых пользователей — это не для слабонервных», — считает Джессика Манн (Jessica Mann) из Southwest Airlines. «Если вы не готовы идти на риск или не верите в успех, вам будет непросто. Чтобы узнать, что за забором, придётся перелезть через него. Откройте своё сердце, учитесь у других, ищите свой путь. Стремитесь к цели и не унывайте».

(Можно раздать ключевым пользователям футболки с надписью «Мы ключ к успеху!».)

Что касается нового сокращённого названия, оно представляется нам крайне удачным — SUN (англ. «солнце», а также аббревиатура для «Super User Network»). Помимо того, что мы придумали с ним отличный заголовок для статьи (в англ. версии «Landing on the SUN»), оно намного короче, чем полный вариант. А значит, и удобнее. Все сразу понимают, о чём идёт речь. Вы вполне можете придумать и собственное название. Но, если вы назовёте проект не сетью, а, например, программой ключевых пользователей (Super User Program, SUP), ваше сокращение будет уже не таким удачным. Мы уже не сможем сказать «SUN rises in the east» (солнце встаёт на востоке). «Here comes the SUN» (скоро солнце взойдёт). «SUNshine» (солнечный свет)... В общем, вы поняли.

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

В первой главе книги, «Мотивация на рабочем месте», мы приводили аргументы в пользу создания сети ключевых пользователей, опираясь на метод от противного. В рамках подготовки формального обоснования проекта по созданию и развитию сети ключевых пользователей (Super User Network, SUN) вы должны будете представить аргументы как в устной, так и в письменной форме, особенно те (как в истории Элис), которые напрямую касаются денег. Мы твёрдо убеждены в том, что первостепенную важность имеют культурные преимущества SUN.

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

Для начала необходимо понять, кто должен сформулировать такое обоснование. Отдел кадров? Почему бы и нет. Вице-президент по корпоративным приложениям? Может сработать. Владельцы бизнес-процессов? Отличная идея, если, конечно, они у вас есть. Обратимся к мнению эксперта.

«Самый эффективный и надёжный способ обеспечить принятие системы — дать конечным пользователям понять, что их комментарии учтены и закреплены в бизнес-случае и функциональных требованиях к новой системе. Применение мнений и отзывов конечных пользователей (особенно тех, кто будет выполнять в новой системе основную часть работы) на самых ранних этапах проектирования, увеличивает вероятность одобрения новой системы на 55 %». Келли Чемберс (Kelly Chambers), блоги CEB.

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

Для начала полезно будет повторить все общие цели, изложенные в предыдущей главе (заранее проработайте своё обоснование).

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

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

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

Вот ещё несколько ёмких рекомендаций для проведения успешной презентации для руководства.

  • Продумайте аргументы в пользу своей идеи до такой степени, чтобы по ним можно было составить прогноз и эффективно измерить полученные в итоге преимущества. Часто можно услышать следующие доводы против:
    • У нас нет механизмов для реализации таких межфункциональных операций.
    • Непосредственные начальники выбранных ключевых пользователей никогда не согласятся на это.
    • Почему пользователи не могут самостоятельно прокачивать свои навыки без посторонней помощи?
    • Почему потребностями пользователей не может заниматься служба техподдержки?
    • Наши сотрудники и так слишком заняты, им не понравится идея взять на себя ещё и эту работу.
  • Представьте наглядные и актуальные примеры измеряемых и прогнозируемых преимуществ.
  • Где возможно, приводите наглядные истории успеха других компаний.
  • Пригласите одного или нескольких союзников, которые будут находиться в зале и смогут помочь вам ответить на неожиданные вопросы. Мнения типа «Я поддерживают это начинание» помогут заронить сомнения в души несогласных.
  • Представьте убедительные выкладки по времени и затратам, пусть в них будет подробно расписано всё, что кажется вам существенным.
  • Не забывайте о ролях и сферах ответственности исполнительного спонсора, участие которого является обязательным. Задача этого человека заключается в том, чтобы a) разрешить вам начать создавать сеть ключевых пользователей и б) отстаивать это начинание на уровне исполнительного руководства, применяя свои глубокие знания, дипломатию и силу убеждения.
  • В заключении необходимо представить чётко сформулированный запрос на первоначальное одобрение объёма, бюджета и сроков. Окончательное утверждение должно быть получено после завершения разработки архитектуры SUN и предоставления руководству плана по развёртыванию.

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

Создание архитектуры сети ключевых пользователей

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

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

В следующем шаблоне организация условно разделена на три области экспертных знаний и ответственности (Рис. 6.1).

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

Рис. 6.1. Позиционирование конечных и ключевых пользователей в общей структуре организации

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

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

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

Возможные роли:

  • конечный пользователь;
  • ключевой пользователь;
  • лидер ключевых пользователей;
  • менеджер сети ключевых пользователей;
  • владелец сети ключевых пользователей;
  • исполнительный спонсор сети ключевых пользователей;
  • организационные партнёры (управление персоналом, обучение, изменения, непрерывная оптимизация, ИТ);
  • эксперт в предметной области;
  • координационный комитет.

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

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

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

...

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

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

Оформите подписку sappro и получите полный доступ к материалам SAPPRO

У вас уже есть подписка?

Войти