Портал №1 по управлению цифровыми
и информационными технологиями

Ключевой компонент сервисных отношений

Опубликовано 30 января 2017
Рубрики: ITSM, Обсуждения на учебных курсах, Управление каталогом услуг
Комментарии

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

По моему субъективному мнению наибольший разрыв между теорией и практикой применения наблюдается в области взаимодействия людей. Может быть потому, что мы в большинстве своём ИТ-шники? Особенно, когда речь идёт о взаимодействии с заказчиками.

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


Причём в документах, раздаваемых участникам тренинга в качестве вводной информации для решения, приведена заведомо неполная информация.

Как вы думаете, как часто группы обращаются с вопросами к тренеру?

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ
VAP: Управление уровнем услуг и каталогом услуг
Разработка каталога, SLA, метрик качества, расчёт доступности

Также по теме:

Комментариев: 20

  • Ольга

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

    • Вадим Томкевич

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

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

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

      Общаться с Заказчиком нужно, но общаться сбалансированно, не много и не мало. И все будет хорошо 🙂

      • Nargiza Suleymanova

        Безусловно, Заказчику проще работать с готовыми вариантами, чем самому их формулировать. В своей практике стараюсь кроме собственно вариантов дать обязательные плюсы и минусы. И когда Заказчик говорит (а они это практически всегда говорят :-)) "Вы же профессионал, что посоветуете?", то предлагаю оптимальный на мой взгляд вариант, но особо акцентирую внимание на том, что решение придется принимать им самим.

        А говорить с Заказчиком лучше много и часто 🙂 Вовлеченность дает хорошие плоды.

        • Игорь Гутник

          Коллеги, спасибо за замечания!
          В целом согласен. Но, как мне показалось, произошла небольшая подмена понятий 🙂
          Я не писал про "много" и "часто". И уж тем более про то, что стоит часто ходить и спрашивать: "Как Вы хотите, что мы Вам сделали?". Вот уж точно, не сервисный подход.
          Нужно, как и написала Ольга в конце комментария, понимать заказчика. Т.е. выяснить его цели (для чего ему нужно то, что заказчик просит/мы ему предлагаем); в чём для него ценность.
          И без общения этого понять не получится.
          То, что на этом пути существуют вышеописанные риски, бесспорно.

          • Nargiza Suleymanova

            Игорь,

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

            То есть формально+неформально=много и часто 🙂

            • Игорь Гутник

              Наргиза, спасибо!

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

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

              И, да, неформальное общение тут тоже может понадобиться.

  • Илья Рунов

    1

    Поддержу коллег. Неоднократно встречал поведение Заказчика, упомянутое Ольгой.

    2

    Автор поста выдвинул только одну гипотезу о причине отсутствия вопросов у Исполнителя. Между тем Исполнитель (как и студент) может предпочесть дополнить "недостающую" информацию от Заказчика своим собственным видением к своей же выгоде. Последствия, конечно, могут быть печальны. 🙂

    • Игорь Гутник

      Илья, правильно ли я понял, что альтернативная гипотеза заключается в том, что сервис-провайдер не общается с заказчиком, поскольку его интерес – только собственная выгода? И именно эта ориентация исключительно на собственную выгоду является причиной игнорирования заказчика?
      Если это так, то, похоже, с выбором картинки-миниатюры для данной заметки получилось очень удачно 🙂
      Я в своих рассуждениях исходил из того, что с обеих сторон существует искренняя направленность на win-win сценарий, присущий сервисным отношениям. Если принять это ограничение, сохраняется ли вопрос к логике рассуждений?

      • Илья Рунов

        Нет, не правильно. Не альтернативная (взаимоисключающая), а дополняющая гипотеза. Не "только собственная выгода", а "и собственная выгода". Иначе говоря, нет единственной причины игнорирования отсутствия запроса на дополнительные коммуникации с Заказчиком.

        В статье основной кейс представлен взаимодействием преподавателя и студента (П-С). И сделан переход на взаимоотношения Заказчика и Исполнителя (З-И). Между тем в реальной жизни, к сожалению, сценарий win-win в большей степени свойственен взаимодействию (П-С), чем (З-И). С одной стороны, возьму кейс Ольги – он достаточно часто встречается в более и менее жёсткой форме при общении (З-И). С другой стороны, редко услышишь от преподавателя "надоело все время слышать вопросы".

        Вот еще одна дополняющая гипотеза: если у студента психологическое препятствие – задать слишком глупый вопрос, то у консультанта (сервис-менеджера?) – риск задать слишком умные вопросы в таком количестве, что это нарушит ожидания заказчика.

        • Игорь Гутник

          Понял. Спасибо!
          Мы подошли к тому, что я и хотел обсудить.
          Ведь в заметке переход от ситуации на тренинге к ситуации в жизни – не мысленный эксперимент. Этот переход в моём повествовании вызван тем, что то, что удалось наблюдать на курсах, очень похоже на то, что приходи[лось/тся] наблюдать в реальной жизни. И будучи клиентом, и, чего уж там, каюсь, находясь на стороне сервис-провайдера.
          Вот и возникли у меня вопросы, обозначенные в конце заметки. Что нужно сделать, чтобы устранить/минимизировать системный дефект в коммуникациях с заказчиком.
          Обсуждение ушло в сторону вопросов: "Стоит ли общаться с заказчиком?", "Почему в некоторых случая стоит ограничить это общение?"
          Возможно, конечно, некоторые участник обсуждения пытаются указать мне на то, что мой тезис о том, что во многих случаях усилий со стороны поставщика услуг по выяснению целей и задач заказчика недостаточно, не верен. Тогда давайте определимся с этим ключевым вопросом.
          Кто согласен с тем, что ситуаций, в которых сервис-провайдер в этом направлении прикладывает не достаточно усилий (речь не только про частоту, но в первую очередь про качество коммуникаций), больше, чем ситуаций, когда поставщик всё делает правильно (в части коммуникаций)?

  • Андрей другой

    Добавлю свои 5 копеек. Как узнать, что требований не достаточно? Как узнать, что даже те, что у вас есть, вы правильно поняли? Единственный, известный мне способ, ответить на эти вопросы – строить модели, формализовать исходные данные. Известные методики как раз и позволят вам на шаге построения модели выснить полноту(описаны все входы и выходы) и непротиворечивость требований(одни требования не противоречат другим). Так что с заказчиком надо общаться, но лучше с помощью формализованных моделей.

    • Игорь Гутник

      Андрей, возможно.
      Не могли бы Вы привести пример?

      Потому как к такой обобщённой конструкции остаётся пара вопросов:
      1. Узнает ли заказчик себя в той модели, которую мы построим? Узнает ли настолько, что сможет адекватно и достоверно судить о том, действительно ли то, что мы ему принесли, это то, что ему нужно?
      2. ОК. Пусть некая модель. Но ведь выяснить, устраивает она заказчика или нет (отвлечёмся от трудности, описанной в п.1) мы не сможем, не пообщавшись.

      Кроме того, поведение заказчика, описанного Ольгой (мне, кстати, очень даже понятное) в случае с общением через модели может выглядеть так: "Вы утомили уже ARISы [или что там у нас] носить на согласование! Вы профессионалы или где?! Сделайте мне хорошо" 🙂

      • Андрей другой

        Я за общение с заказчиком. Вопрос – на каком языке. Обычное, вербальное, общение сопряжено со множеством недоразумений, вызванных широким толкованием терминов и большой неопределенностью. Модель в этом случае –  идеальное решение, поскольку допускает только однозначное толкование. И чем более убогая нотация, тем лучше. Aris в этом случае излишне гибок на мой вкус. Лично я предпочитаю IDEFх. Там без вариантов : вход процесса, выход, контроль(инструкции, регламенты), инструменты (в частном случае ИТ сервисы). ЧТо касается "вы профессионалы или где?" я поступаю следующим образом, сначала беру у закзачика все имеющиеся инструкции, регламенты, все что уже написано, и по ним строю модель. Уже на этом шаге вылезает куча всего. Потом с этой моделью иду к заказчику. В большинстве случаев реакция – "а мы не это имели ввиду"(когда писали все эти инструкции и т.д.). Далее предлагем возможные пути выхода – строим целевую модель. Тут да, как профессионал вы должны предложить варианты и связанные с ними риски, чтобы заказчик осознанно выбрал устраивающий его вариант.

        1. Узнает ли себя в модели. Это зависит от уровня детализации модели. Случай из жизни – Юрий Ипатов(заказчик) в свое время требовал у исполнителей разработать модель. Обиженные, они спросили: "До какого уровня детализации". Ответ – "до такого, чтобы я мог отличить металлургический комбинат от птицефабрики".

        • Игорь Гутник

          Андрей, вроде бы всё логично…. Но пример сильно помог бы.
          Пока мы имеем пример про господина Ипатова, который, вроде бы как, опровергает тезис о необходимости детальной модели (вряд ли данный заказчик просил принести ему IDEF).

          • Ольга

            Игорь, вот выдуманный пример, но он, на мой взгляд, хорошо подходит: https://habrahabr.ru/post/301924/. Суть же дискуссии, мне кажется, сводится не к количеству коммуникаций, а их качеству, как вы выше заметили. На мой взгляд, необходимо проявить дотошность при выяснении целей заказчика, но постараться смирить свои порывы по уточнению технических деталей. В технике допустимо сформулировать свои исходные допущения, на их основе предложить первую версию решения для обсуждения с заказчиком и по ходу скорректировать или получить дополнительную информацию. Но разные заказчики имеют разные представления о границах допустимого погружения в детали, и тут необходимо понять предпочтения конкретного заказчика, что, конечно не всегда получается. И, как отметил Илья, возможно, не совсем корректен прямой перенос взаимодействия преподавателем и студентом на взаимодействие между заказчиком и исполнителем 🙂

            • Игорь Гутник

              Ольга, спасибо!

              Отличная история. К сожалению, мы совсем уйдём от вопросов, которые я обозначил изначально, если углубимся в её разбор (а ведь очень хочется 🙂 поскольку он, на мой взгляд, в т.ч. прекрасно демонстрирует то, как сервис-провайдер зачастую себя ведёт, и как некоторые участники обсуждения восприняли тезис о "хороших" коммуникациях [=задать побольше вопросов]. Тогда как, "хорошие" коммуникации, как мы вроде бы уже все договорились – это не только про правильную частоту. Но это действительно большая тема, требующая отдельного обсуждения).

              И, как отметил Илья, возможно, не совсем корректен прямой перенос взаимодействия преподавателем и студентом на взаимодействие между заказчиком и исполнителем

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

              Чтобы вернуться в русло, нужно определиться с одним вопросом.

              Вы согласны с тем, что ситуаций, в которых сервис-провайдер в этом направлении прикладывает не достаточно усилий (речь не только про частоту, но в первую очередь про качество коммуникаций), больше, чем ситуаций, когда поставщик всё делает правильно (в части коммуникаций)?

              И, если согласны, что с этим делать руководителям на стороне сервис-провайдера? Вот основной вопрос, который сформулирован в статье.

               

              • Ольга

                Игорь, на первый вопрос ответ: да, согласна.

                По второму вопросу несколько тезисов сформулирую как руководитель на стороне сервис-провайдера :):

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

                2. Подбирать сотрудников, которые способны решать задачи изложенным выше способом 🙂

                • Игорь Гутник

                  О! Супер!
                  Т.е. у вас эта практика даже каким-то образом формализована.
                  Ольга, а как, если не секрет, осуществляется подбор этих "правильных" сотрудников? Эта часть как-то формализована? Тесты, кейсы, собеседование…? Как выявить эту компетенцию? Или это не компетенция, а склад характера, который дополняете необходимыми навыками? Тогда как выявляете нужный склад характера? И как обучаете?

                  • Ольга

                    Игорь, очень большая тема, в двух словах не скажешь. Если обобщать:

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

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

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

                    • Игорь Гутник

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.