Блог Александра Башкирова

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

конференции

Конференция "Адванта: Внедрение проектного управления - 2017". Послесловие.

Просмотров: 23Комментарии: 0
Alib.spb.ru

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

Начну с "дорожных впечатлений", то есть - с поругания Аэроэкспресса. Заказать билет ни через сайт, ни через приложение - никак. При этом коллега, который 2 часами ранее оформил заказ - также заказать не смог. С касс - всё купилось с первого раза.

Также из "дорожного": порадовала авиакомпания Алроса. Отличное обслуживание (в стиле "как раньше было у всех") и отличный ужин. Прям пять баллов =)

По существу. Быть спикером (был им на прошлой конференции), и быть в команде организаторов - это две большие разницы. Очень большие разницы. Но, с другой стороны - где, как не на таких "водопадных" мероприятиях проявляется командная работа. Наши коллеги готовили конференцию - и отзывы клиентов говорят, что работа была проделана не зря. Мы - команда конференции - помогали организаторам чем могли, когда могли и сколько надо. И именно поэтому, как мне кажется - результат получился такой, какой он есть. У нас не было вопросов на тему "почему я" - мы просто брали и делали. Это было круто.

Про саму конференцию скажу - что я не был ни на одном докладе, который хотел бы посетить. Что поделать - работа "за кулисами" съела все время. Из того, что успел посетить - доклады понравились. Их того, что запомнилось - слушал как рассказывает Андрей Бадин - и радовался тому, что есть движуха, что проектное управление в формате "как и должно быть" пошло и в органы власти. Был экспертом на круглом столе "Внедрение ИСУП". Там состоялся на мой взгляд интресный диалог. Ярослав Рашевский модерировал - и не давал расслабиться :) Ну и конечно же много общался с клиентами, с многими из которых был знаком только заочно.

Про закулисную работу говорить ничего не буду, разве что скажу - не путайте туризм с эммиграцией :) для себя сделал вывод, что хорошо поставленная закулисная работа - это основа основ для того, чтобы мероприятие "взлетело". Так что снимаю шляпу перед продюсерским комитетом (Марианна Крель), подготовившим отличную программу и РП проекта "Конференция" (Женя Касабекова), которая выдержала и сделала мероприятие очень достойного уровня.

Ну и - до встречи в следующем году, на "Адванта-2018" :)

PS. Получилось немного сумбурно, но зато "по горячим следам" ))))

Еще про DUMP2017: Видео - Проблемы неестественных интеллектов. Интеллекция Григория Бакунова («Яндекс»)

Просмотров: 251Комментарии: 2
Alib.spb.ru

Еще про DUMP2017: Видео - Проблемы неестественных интеллектов. Интеллекция Григория Бакунова («Яндекс»). На этом докладе я не был, коллеги поделлись ссылкой.

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

DUMP2017 в Екатеринбурге - впечатления.

Просмотров: 484Комментарии: 0
Alib.spb.ru

Был в качестве слушателя-участника на конференции DUMP2017 в Екатеринбурге. Это, кстати, первое ИТ-шное мероприятие, которое я посетил в этом городе (и искренне надеюсь, что не последнее).

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

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

На каких докладах был:

1) Создание системы логирования (Андрей Литуненко, 2ГИС) - сам по себе доклад интересный. Вопрос только в том, что именно для меня там ничего нового не было, ну разве что с удивлиением узнать, что lua используется не только для создания конфигов awesome :) Хотя народ слушал с удовольствием.

2) Как повысить мотивацию удаленных разработчиков и повысить значимость каждой задачи (Александра Перфилова, SkyEng). Тут было много интресного в части того, чтобы выслушать опыт того, как бывает. Скажу, что результат впечатлил - полностью удаленная, и судя по рассказу - высокомотивированная команда. Тот случай, когда поучиться не грех, тем более, что Саша с удовольствем делилась секретами мастерства.

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

4) Как поднять цену и не потерять в продажах (Дмитрий Клаев, ФРИИ). Опять "вроде бы очевидно", но очень хорошо структурировано и рассказано. Было видно, что рассказ "не просто так", в том смысле, что Дмитрий знает о чем говорит... но недоговаривает:) Что, в общем - неудивительно.

5) Внедрение UX стратегии (Юрий Ветров, Mail.ru) - интереснейшее выступление. Там очень органично сочеталось "что мы сделали", "как мы это сделали" и "почему мы слелали именно это", плюс - обобщаюбщие выводы и ремарки. С моей точки зрения - идеальный баланс для рассказа, когда нет ухода в "я-крут" и нет ухода в "стратегию, тактику и смотрите-как-надо". А сам доклад интресен - действитльно интересен, потому что он наполнен практикой. А еще потому что рассказ был интресен не только дизайнерам.

6) Чем отличается дизайнер в продуктовой компании от дизайнера в агенстве или студии? (Денис Кортунов, Acronis). Ну что сказать... Если предыдущий рассказ был интересным и живым, то после этого сложилось впечатление, что рассказчик занял позицию "дизайнер всегда прав, не трогайте дизайнера". И если предыдущий рассказчик как раз очеь соблюдал баланс между "что-как-почему", то тут сложилось впечатление, что рассказчик немного оправдывается и концентрируется на "что". В итоге рассказ получился интересным, наверное, для профессоналов - но для "не-профи" он показался очень смазанным.

7) Профессиональное выгорание менеджера проекта. (Александр Орлов, Школа менеджеров Стартоплан). На мой взгляд - худший доклад из всех, на которых я был. Если коротко, то "выгорание это плохо", "когда выгорание просиходит - оно происходит вот так", "есть фриланс-помощники, за 300 рублей они всё сделают". В общем, тема не раскрыта, с моей точки зрения.

8) ChatOps: час в центре DevOps архитектуры. (Эдуард Медведев, Brocade). С моей точки зрения - очень интресный и насыщенный рассказ о том, как можно реализовать DevOps - просто. Без лишних подробностей, но с достаточной степенью детализации, чтобы понять идею. С примерами решений. Мне очень понравилось! Правда, аудитория была немногочисленной - "самые технари", но рассказ однозначно того стоил.

Я был в составе команды Адванта Консалтинг - так как с марта работаю в этой компании. Адванта "десантировала" на мероприятие хорошую команду: разработчики, аналитики, тестировщик и директор по разитию бизнеса. Вот все мы:

Ну и про атмосферу. Как я говорил, на мероприятии было около 1200 человек (оценочно), в залах зачастую не хватало мест, поэтому нередко можно было увидеть такую картину:

А вообще залы были полные:

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

Так что, повторю еще раз - остался очень доволен. Респект организаторам - It-People (https://www.it-people.ru/). Сайт конференции: http://dump-conf.ru/

Я на конференции “Внедрение проектного управления 2016” (Advanta Group)

27 октября 2016 года был на конференции “Внедрение проектного управления 2016”, организованной Advanta Group (http://www.advanta-group.ru). Выступал с докладом “Как бизнес приходит к необходимости внедрения проектного управления”. Слушал доклады коллег.

Коротко стенограмма доклада (отредактированная версия, она больше иллюстрирует слайды… поэтому есть смысл читать их, глядя в слайды):

Представим себе ситуацию. Вы приходите в компанию. А там - бардак, больше непонятно, чем понятно, но все живут в этом, не пытаясь найти выход. При этом - ситуация дружно не устраивает абсолютно всех. Что же делать?

По сути, классическим путём решения обозначенной проблемы является внедрение регулярного менеджмента. Я не буду рассматривать крайние случаи, когда строится компания типа new age - а рассмотрю самый простой, 90% имеющий место быть вариант. Но регулярный менеджмент - это очень общее понятие, поэтому рассмотрим что может из набора его инструментов помочь в текущей ситуации. Наверное, самое простое, что можно сделать - это в том или ином виде внедрить проектное управление.

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

Как известно, есть 2 основных пути развития: революция и эволюция. Каждый из этих путей имеет свои плюсы и минусы. И наверное, для некой абстрактной компании сложно сказать - какой путь будет более правильным. Тут многое зависит от тех, кто ставит цели, стоит у руля. Кто-то хочет получить мгновенные быстрые результаты, хоть в чем-то. Кто-то - отлаженный процесс на выходе. На самом деле, скорее всего - результат будет гибридом “революции” и “эволюции”, но вот процентное соотношение будет в каждом случае разное.

Далее рассмотрим, что влияет на этот баланс, на выбор процесса.

История из опыта. Придя в одну компанию, я попал в ситуацию, которую отразил ранее: непонятно, кто что делает, примерно понятно кто за что отвечает. При этом - определение конкретного ответственного было моим персональным адом. Соответственно, есть масса активностей проектных, непроектных - без конкретного ответственного. РП в явном виде отсутствовал. Были некие “кураторы”, которые не хотели нести ответственность даже за то, что за ними закреплено по приказу.  Получение статуса как практически любой задачи, так и по активности в целом там вообще требовало привлечения детективного агентства… ну и до кучи - контроль расходов по активности в разрезе управленческой отчетности был отдельной головной болью. В итоге, при “продаже” идеи ПУ она нашла отклик в сердцах всех ТОП-менеджеров, и, забегая вперед - внедрение было весьма удачным.

Но не следует думать, что внедрение ПУ всегда проходит только “сверху”. Давайте теперь поговорим об исполнителях и о том, что для них является “красной зоной”, сигнализирующей о том, что есть запрос на внедрение ПУ - снизу. Расскажу еще одну историю, из опыта.  Была некая компания, где я также работал достаточно давно. В компании была классная команда, сконцентрированная на одной цели… были некие направления деятельности. Проблема была в том, что не было выделено явных единых точек ответственности, жизнь была под лозунгом “дедлайн не пройдет”, то есть регулярный подвиг. И всё это считалось нормой.

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

В итоге, команда “пришедших” в связи с расширением бизнеса менеджеров и исполнителей достаточно быстро выявила и обострила проблематику. Было принято решение о внедрении УП, УП внедрено… примерно в это же время компания был продана большому игороку в отрасли, где были свои стандарты управления проектами. Но это уже совсем другая история.

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

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

Рассмотрим теперь ожидания от внедрения УП. Это важный показатель, так как не имея представления о цели и об ожиданиях, запросто можно прийти не туда.  Из практики, применительно к ожиданиям есть 2 ситуации. Первая, при которой степень зрелости организации низкая. Вторая - при которой степень зрелости высокая. Как водится, и ожидания в представленных ситуациях будут разными. При низкой степени зрелости - ожидания будут лежать в плоскости “оно само, а я тут рядом постою”, при высокой - будут требовать конкретные показатели.

Совет: при старте проекта внедрения УП, определите степень ожиданий, основные цели и подцели. Хотя бы для себя. Тогда и проект проще вести, и ориентиры будут четкие.

И тут возникает важный, ключевой вопрос. Стоит ли вообще внедрять проектное управление, или не стоит.

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

Давайте зададимся вопросом: а когда проектное управление - вредно?

В моей практике не было таких случаев, но старшие товарищи поделились шикарной историей. Некое гос.предприятие приняло решение о повышении эффективности и внедрении УП. Решение было директивным. УП внедрили, что называется “до последней копейки”. В результате… увеличился штат (создан отдел управления и поддержки проектной деятельности), увеличилось время (теперь оформляем не только по ГОСТ но и по-проектному). Спустя 2 года - ведутся разговоры о сокращении… под раздачу первыми судя по всему, пойдут те самые проектанты.

Вывод: не все УП одинаково полезно.

А теперь рассмотрим положительный пример внедрения проектного управления.

В одной организации поводом для внедрения УП было то, что сбор статуса занимал… порядка 30% по времени от всего проекта. 30% на статус - это не просто много, это неоправданно безобразно много! И еще один кейс - когда руководство устало от выдающихся достижений в проектах до такой степени, что однажды директивно “спустило” подготовленные правила игры (по сути - ввело УП), и начало жестко спрашивать за их исполнение.

Про возражения.

УП никогда не внедряется “просто так”. УП всегда внедряется через возражения. Почему возникают возражения? Потому, что кто-то недоволен, кто-то боится, кто-то ощущает угрозу… Возражения возникают и тогда, когда сотрудник понимает, что внедрение УП может пошатнуть его положение.

Далее, рассмотрим, какие бывают возражения и как с ними работать.

эмоциональные: например, мне возражают “это бесконечно, а нам - некогда”. Работаем с эмоцией, объясняем, что будет создан специальный комитет, например, то есть текущая деятельность не пострадает, для пилота будет выделен один небольшой проект, постепенно конечно все проекты перейдут на УП, но все сделано именно для того, чтобы обеспечить бесшовный переход.

ценностные: например, мне возражают “у нас это никогда не заработает”. Принимаем: “ок, вы работаете на данной позиции достаточно давно, для того, чтобы делать такие выводы. Но давайте посмотрим: у вас есть уникальный опыт, который до сих пор не давал осечек. Давайте обсудим, какие мероприятия, с учетом именно Вашего опыта и знаний могли бы улучшить ситуацию?” - после чего подводим к мероприятиям внедрения УП, и указываем, что это оно и есть. Как вариант - принимаем ценные идеи на внедрение.

рациональные: например, мне возражают “кажется, что внедрение УП приведет к излишней бюрократии”. Разговариваем на языке фактов. Оцениваем время сейчас, с учётом всех рисков, оцениваем время после. Оцениваем бюрократию сейчас. Оцениваем после. Оцениваем неразбериху сейчас. И порядок после. Подводим к позитивным выводам.

Ну и в завершении расскажу о сложностях, которые подстерегают тех, кто решился на внедрение ПУ, на начальном этапе. А вот что с ними делать? Все эти сложности по большому счету, лежат либо в области неопределенности от процесса и результата, либо в области человеческих интересов. Как работать с этими сложностями? Во-первых, о них надо просто не забыть. Во-вторых, каждую сложность можно проработать антитезисом. Например, “ожидание быстрых результатов” - шикарно может быть положено в концепцию внедрения ПУ, если принять в качестве КТ выдавать некие практически используемые результаты. Например: через месяц составлен реестр проектов, через два - определены основные метрики проектов и принят проект-пилот и т.д.

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

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

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

Как я не попал на "Второй план Б" и что из этого вышло

Нет, я не тормоз:) И лучшее тому доказательство - что я все-таки сел писать этот пост. Несмотря на то, что времени прошло почти 3 месяца. Но - обо всем по порядку.

23 февраля 2013 года славная компания Яндекс проводила мероприятие под названием "Второй план Б". Я туда подал заявку на спикерство, но - пройдя несколько итераций был забракован, как "не формат". Впрочем, что не делается - к лучшему: 23его я оказался категорически занят. А так на меня и не рассчитывали. В общем, все бы было неплохо, если бы не одно маленькое "но": я готовился, и готовился очень серьезно. Презентация, которая получилась на выходе, мне лично казалась довольно удачной ... в итоге, подумав, решил, что презентация стоит того, чтобы выложить ее тут. В конце концов, она делалась, чтобы стать достоянием общественности. Так почему нет?

В общем, вот: Второй план Б - презентация

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

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

В пользу бедных

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

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

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

В общем, жизнь - это вечный поиск компромисса. Во всем.

Кросспост из моего ИТшного блога на ITBlogs.ru

Contact Center Forum – тезисы одного доклада

Просмотров: 3178Комментарии: 0
IT Blogs

29 ноября в Санкт-петербурге, отеле Ambassador, состоялось мероприятие под названием Contact Center Forum.

Я выступал там с докладом "Self Service Contact Center как инструмент повышения удовлетворенности потребителей" (тот самый докладчик, информация о котором уточняется:) )

Собственно, в блоге я решил сформулировать основные тезисы выступления: вдруг кому пригодится?

Итак.

Contact Center - это инструмент для следующих целей:

  • Маркетинговых
  • Коммуникационных
  • Повышения лояльности
  • Аналитический

Классический Contact Center - это прием и обработка обращений потребителя, при этом обработка обращений происходит по заранее оговоренным правилам, в соответствии с SLA.

Создание Contact Center - это задача, которая требует определенных инвестиций. В то же время одним из инструментов повышения прибыли компании является сокращений издержек. Издержки на Contact Center можно попробовать сократить, внедрив в его работу механизмы Self Service. Или организовав Self Service Contact Center.

Что такое Self Service Contact Center с точки зрения оператора услуг? Это, в первую очередь, набор приложений (web, sms, ussd, ...), позволяющих автоматизировать работу потребителя по получению информации и(или) управления предоставленными услугами. Далее, это пополняемая база знаний, причем пополняемая она сотрудниками оператора услуг, в соответствии с определенными методиками и регламентами. И, наконец, это политики предоставления доступа к Self Service Contact Center и его использования. В целом же, SelfService Contact Center - это сервис, предоставляемый оператором услуг их потребителю.

Что такое Self Service Contact Center с точки зрения потребителя? Это персонифицированная информация, публичная информация, скорость и надежность сервиса.

Следует отметить, что Self Service Contact Center в большинстве случаев не заменяет, а дополняет традиционный Contact Center.

Кто использует Self Service Contact Center?

  • Банки
  • Телекоммуникационные компании
  • Туристические компании
  • В общем случае - провайдеры услуг

Для организации Self Service Contact Center необходимо, чтобы провайдер услуг соответствовал следующим требованиям:

  • Он должен предлагать на рынок понятный потребителю продукт
  • У продукта должен быть понятный потребителю регламент обслуживания
  • У провайдера услуг должна быть внедрена и развернута соответствующая обеспечивающая база (например, система активации телекоммуникационных сервисов)
  • Должна быть обеспечена альтернативная поддержка и доступная справка по использованию Self Service Contact Center (что подтверждает тезис о том, что Self Service Contact Center дополняет традиционный Contact Center)

Кроме этого, пользователь Self Service Contact Center также должен соответствовать некоторым требованиям, в частности:

  • У него должен быть средний уровень технической грамотности
  • Он должен уметь пользоваться базовым средством доступа к Self Service Contact Center
  • Он должен иметь четкое представление по возможностям и последовательности действий по отношению к Self Service Contact Center
  • У него должен быть высокий уровень ответственности

Технологически Self Service Contact Center может представлять собой:

  • web-сервисы (текст, графика, голос, видео) - то есть пользователь работает с сайтом (закрытой персонифицированной частью)
  • sms (пользователь формирует специальные sms, отправляя их на специальный номер)
  • ussd (пользователь формирует специальный ussd запрос)
  • special call (пользователь звонит на специальный номер и использует систему голосового меню, либо пользователь звонит на специальные номера, в зависимости от номера, на который он звонит, происходит то или иное действие)
  • special email (пользователь формирует email на специальный адрес с указанием кода дейтствия)

Инструментами для реализации Self Service Contact Center являются:

  • портальные решения
  • SMS, Email, USSD шлюзы
  • Голосовые навигационные платформы
  • Средства активации

Таким образом, Self Service Contact Center это:

  • Современное решение, позволяющее минимизировать издержки и сфокусироваться на потребителе
  • Удачное дополнение традиционного Contact Center
  • Максимальная доступность для потребителя

Self Service Contact Center используется в основном там, где необходимо массовое обслуживание потребителей.

После этого я привел один пример - управление интеллектуальными услугами, и, ответив на ряд вопросов, скрылся в рядах слушателей:)

Оригинал и комментарии на ITBlogs.ru