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

Ginger Luttrell & Michael Doane

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

*Оригинал (англ.): Настольная книга ключевого пользователя. Джинджер Латтрелл, Майкл Доан. Enterprise Alliance Press. Глава 5. 2017, с. 99–120.

Корректура: Юрий Нечитайлов.

Ориентация на выгоду для бизнеса. Как конечные пользователи помогают получить измеримые бизнес-преимущества // SAP Professional Journal Россия, январь–февраль, №1 (78), стр. 4–17. @ 2020, Джинджер Латтрелл, Майкл Доан.

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

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

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

1. Проблемы с обучением со стороны специалистов службы поддержки: каждый звонок, который не потребовался бы при более высокой компетентности конечных пользователей, снижает общую продуктивность работы, поскольку тратится время на приём звонка, описание проблемы, регистрацию обращения и получение ответа через некоторое время. Всё это, разумеется, не считая стоимости работы специалистов службы поддержки, как внутренних, так и сторонних.
2. Проблемы с дисциплиной: конечные пользователи, которые не до конца понимают, как выполнять те или иные задачи, ощущают постоянный дискомфорт и стремятся в максимально возможной степени избегать общения с системой. Это приводит к замедлению бизнес-процессов или даже к полной их остановке.
3. Увеличение числа ошибок в транзакциях ведёт к потери времени на их исправление, выверку и бесконечные переделки.
4. Отсутствие взаимодействия между конечными пользователями и архитекторами бизнес-процессов ведёт к появлению всё новых изменений в процессах, в результате чего пользователям становится трудно их выполнять. Процессы замедляются ещё сильнее, число ошибок операторов растёт.
5. Сокращается межфункциональная поддержка в связи с отсутствием сотрудничества по горизонтали, поскольку не имеющие достаточного опыта или знаний пользователи не могут помочь друг другу. Что может быть хуже? Только двойная работа, которую приходится выполнять сотрудникам. Или бесконечные попытки предлагать различные решения одних и тех же проблем в разобщённых отделах, у которых просто нет мотивации, либо отсутствуют каналы для совместной работы.

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

<…>

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

1. отсутствие инфраструктуры в помещении, где обучение проходит от случая к случаю и без определённой подготовки;
2. бесконечные ошибки, поскольку грамотные коллеги совершенно необязательно будут хорошими учителями или наставниками;
3. двойные затраты, поскольку затраты на обучение сторонними специалистами в два раза ниже, чем при обучении коллегами на местах;
4. невозможность повторения, поскольку каждый сеанс обучения коллегами ситуативен;
5. невозможность измерения результатов.

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

Гас Лопес (Gus Lopes): «В настоящее время более 85 % всех официальных технических учебных материалов SAP разрабатывается и поставляется ключевыми пользователями. Это само по себе уже потрясающее достижение. И успех можно считать ещё более значительным, если учесть, что наши ключевые пользователи дают коллегам узкоспециализированные знания, которых просто нет у людей извне».

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

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

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

Предлагаем вам самостоятельно подсчитать размер сэкономленных средств при сокращении числа звонков в службу поддержки на 25 %. В то время как стоимость одного часа работы службы поддержки по общим и техническим вопросам в компаниях сильно разнится, описанный сценарий цикла обращения весьма распространён (см. Табл. 5.1).

Табл. 5.1. Сообщение о проблеме: «Я пытаюсь сохранить заказ, но выводится сообщение об ошибке»

Полный цикл решения вопроса в таком сценарии длится от одного часа до двух дней. Всё это время заказу клиента не уделяется никакого внимания (единственное движение, которое происходит вокруг него — рост затрат, которые могут оказаться вполне существенными, если в итоге этот заказ всё-таки будет потерян). Ещё более серьёзной является хроническая проблема с приёмом заказов, когда клиента теряют уже на этом этапе. Думаете, такого просто не может быть? Вы уверены? Спросите водителей такси про Lyft и Uber. («Уважаемая служба поддержки клиентов, качество вашего обслуживания просто отвратительное. Прощайте навсегда.»)

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

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

Непрерывная оптимизация бизнес-процессов: это образ жизни, который вам понравится

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

Рис. 5.1. Кривая производительности при осуществлении нарастающих улучшений

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

Майкл не отказался бы получить по монетке за каждого клиента на своей памяти, который внедрил очень мощные корпоративные приложения с помощью очень дорогого интегратора систем, а описание их бизнес-кейса по степени воодушевления выглядело как восторженные пожелания на поздравительной открытке Hallmark:

• Оптимизируем наши процессы! (что значит «оптимизируем»?)
• Сократим уровни запасов! (на сколько и зачем?)
• Привлечём новых клиентов! (как и сколько клиентов?)
• Увеличим объём продаж! (для всех трёхсот семидесяти четырёх тысяч позиций, которые мы продаём?)
• Продлим обед до трёх дня! (я согласен!)

Майкл рассказал нам, как однажды потенциальный клиент сказал ему, что в его компании царит полный бардак и ему нужно больше «компьютеризации». Когда я сделал попытку направить обсуждение в сторону оптимизации бизнес-процессов с помощью компьютеризации, потенциальный клиент раздражённо заявил мне: «Мы теряем пять тысяч долларов ежедневно, нам срочно нужно всё ускорить!» Очевидно, что разумнее было промолчать, но я ответил, что если мы просто «всё ускорим», он может начать терять по десять тысяч долларов ежедневно. Я не знаю, удалось ли ему компьютеризировать свою компанию. Больше я его не видел».

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

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

Лора Зейн (Laura Zaine) работала над проблемой конечных и ключевых пользователей так же долго, как и Джинджер (более 20 лет). Итак, она пришла к следующему выводу: «Организации, которые реализовали/создали сеть ключевых пользователей, смогут сократить расходы благодаря росту эффективности процессов, снижению числа ошибок, более быстрому решению проблем и повышению качества обслуживания клиентов».

Гас Лопес (Gus Lopes) пошёл дальше: «Любая программа и любой проект должны демонстрировать свою ценность. Памятуя об этом, мы приступили к разработке калькулятора рентабельности инвестиций, чтобы можно было продемонстрировать экономию средств и рост продуктивности как прямое следствие реализации проекта по ключевым пользователям. Эта работа ещё не завершена, необходимо принять во внимание множество переменных, но начальный анализ показывает, что программа по ключевым пользователям приносит не менее 400–500 % возврата от инвестиций».

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

1. Практические изменения процедур

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

Лора Зейн добавляет, что в учебных средах пользователи слишком подстраиваются под ИТ-процесс. Им необходимо изменить такой образ мыслей и во многих ситуациях просто применять здравый смысл. «Доверять себе не менее важно, чем уметь работать с приложением».

2. Технологические изменения

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

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

3. Изменения на платформе приложений

Эти изменения становятся возможны после внедрения в портфеле приложений новой функции или гибкой опции. Если все решения о таких изменениях принимаются ИТ-отделом/службой технологической поддержки без обсуждения с ключевыми пользователями, компания может так и не получить предполагаемые операционные преимущества (о чём ИТ-отдел даже не узнает ввиду отсутствия собственно пользователя в этом контексте).

Проектный опыт

Джинджер приводит пример из своего опыта.