Создание техподдержки. Support-Desk — создание центра поддержки для своего бизнеса. Что в идеале хотели бы от нас

Видеопомощь

В этом видеоролике описана следующая информация:
— Общая информация о проекте;
— Процедура регистрации в сети православных сайтов Prihod.ru;
— Авторизация в сети православных сайтов Prihod.ru;
— Как создать свой первый сайт в сети;
— Заполнение формы регистрации сайта;
— Основная информация о шаблонах сайтов.

Если вы уже создали сайт, то наведите курсор на «Мои сайты» в левом нижнем углу и в выпадающем меню выберите пункт «Добавить сайт».

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

Вы сможете отредактировать введенные данные в консоли сайта в разделе «Регистрация».

Форма регистрации сайта

При заполнении полей слева в черном окошке появляется подсказка по заполнению этого поля. Если вы ввели ошибочные данные, об этом также выведется уведомление красным шрифтом.

Вкладка «Помощь». На вкладке «Помощь» вам предлагается ссылка на видеоролик, в котором рассказывается, как заполнять поля при регистрации. Если у вас нет возможности его просмотреть, вы можете использовать эту инструкцию.

Также на вкладке «Помощь» вам будет предложено выбрать основной язык сайта.

Чтобы перейти к регистрации, нажмите кнопку «Далее».

Первый шаг. На первом шаге регистрации нужно указать общую информацию о сайте.

Сначала выберите страну, от этого зависит на каком домене будет находиться Ваш сайт. Каждому сайту на Prihod.ru дается доменное имя третьего уровня. Для Украины это домен church.ua, для всех остальных стран — cerkov.ru или для православных организаций pravorg.ru. В дальнейшем вы сможете .

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

Имя сайта (домен) — укажите имя, которое будет у вашего сайта. Нажмите кнопку «Проверить», чтобы посмотреть, доступен ли этот домен для регистрации.

Если вы не планируете использовать его как основное и у вас есть свой домен, который вы будете привязывать, или создаете пробный сайт, не занимайте хорошие домены (например, pokrov), оставьте их тем пользователям, которые будут использовать эти имена как основные.

Обратите внимание! Сайты, относящиеся к Украинской Православной Церкви , в обязательном порядке должны иметь доменное имя на church.ua (например, vashHram.church.ua).

Итак, у вас получится доменное имя вида domain.cerkov.ru, domain.pravorg.ru или domain.church.ua.

Мы не рекомендуем указывать полное название храма (Местная Православная религиозная организация ‘Приход храма такого-то’), т.к. получается очень длинное название, это сбивает с толку непросвещенных мирян. Лучше указывать так: ‘Храм Живоначальной Троицы, поселок Доброе’.

Второй шаг . На втором шаге

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

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

Сменить шаблон уже в процессе работы над сайтом нельзя , но вы можете просто удалить ненужные страницы, рубрики и записи или добавить новые. Самый кардинальный вариант — удалить полностью сайт и создать заново.

Как настраивать темы, работать с наполнением сайтов, настраивать боковые колонки и меню подробно рассказано в разделе , там выберите нужный раздел в правой колонке.

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

Люди обмениваются острыми словами,
- сказал Локи, - но эти слова ничего не весят.
У человека во рту их много.
«Empire V», В. Пелевин.

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

К то работает в службах поддержки? Каким должен быть саппорт? Как быть хорошим «саппортером»? Об этом вы узнаете в этой статье.

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

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

П оэтому устраивайтесь поудобнее и приступим.

Как подобрать сотрудников в техподдержку

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

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

Н о такое бывает крайне редко и, чаще всего, владельцу приходится самому выполнять функции саппорта. Достаточно ли у вас времени и терпения, чтобы выполнять эту работу? Окупится ли такой подход в перспективе?

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

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


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


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


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


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


• Сотрудник службы поддержки пользователей должен быть доступен .
  Если в службе поддержки работает один человек, он должен иметь возможность быть в как минимум 12 часов в сутки. А лучше 14-18 часов (при не слишком плотной нагрузке). Если нагрузка сильная, необходимо организовывать сменные дежурства. Но главное - служба поддержки должна быть доступна большую часть суток. Пользователи не должны её «вылавливать». Ну, а, например, для техподдержка в режиме 24/7 (24 часа 7 дней в неделю) - уже давно общепринятый стандарт.


• Некоторая работа на себя - не помеха .
  Не запрещайте сотруднику техподдержки немного работать на себя. Если он в свободное время развивает пару или пишет , то работе в службе поддержки это нисколько не помешает. Зато поддержит его в хорошей профессиональной форме и поможет финансово.


• Не обезличивайте сотрудников службы поддержки .
  Как показали опросы, с сотрудником поддержки удобнее общаться, если у него есть нормальное имя (ник). То есть ник в ICQ «John Smith» намного лучше, чем Support Unit 1».


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

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

Что нужно для работы в техподдержке

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

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


• 12 часов в день - минимум .
  Служба поддержки должна быть доступна большую часть суток. Она действительно ценна тогда, когда к ней можно обратиться за помощью в любой удобный момент. Поэтому у вас должна быть возможность присутствовать в сети минимум 12 часов. А лучше и 16. Конечно, сидеть безвылазно всё это время на месте нереально, поэтому придумайте способ заниматься другими делами и в тоже время находиться в онлайне. Можно носить с собой смартфон. Можно просто ставить звук погромче, когда занимаетесь домашними делами, и прибегать к рабочему месту, услышав знакомое «тук-тук». Будьте готовы вставать и посреди ночи. А кому сейчас легко?


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


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


• Никогда не игнорируйте .
  Никогда, никогда не игнорируйте сообщения! Работник службы поддержки обязан отвечать на все запросы, будь то ICQ, e-mail, тикеты или телефон. Не имеет значения, кажется вам проблема в этом сообщении важной или нет, потому что для адверта любая его проблема исключительно важна. Её обязательно надо решить и, по возможности, быстро. Более того, чаще всего, чем меньше цена вопроса, тем больше вероятность скандала. Так, например, при задержке выплат, партнёры, которые еле набрали минималку, беспокоятся в разы больше, чем крупные адверты. Для новичков их первые 50$ имеют огромное значение. Не допускайте, чтобы из-за них началась буза где-нибудь на форуме.


• Будьте внимательно и гибки .
  Техподдержка - лицо компании. Поэтому общение с ней должно оставлять приятное впечатление. Будьте вежливы, внимательны и всегда старайтесь подстраиваться под обратившегося к вам. Если обращаются на «Вы», говорите «Вы», если «тыкают», ведите беседу по-приятельски.


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


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


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


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


• Не допускайте негатива на форумах .
  Отсутствие негативных отзывов на форумах - это хорошая работа техподдержки. Никогда не доводите до публичных разбирательств, даже если вы на 200% правы в споре. Как сказал кто-то из классиков маркетинга, «в споре с клиентом ещё никто не побеждал». Я бы добавил, что в споре с адвертом - тоже.


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


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


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

В опреки мнению многих, работа в службе поддержки - это не пустая болтовня в ICQ для тех, кто больше ничего не умеет. От качества работы этой службы зависит мнение компьюнити о проекте, что, в конечном итоге, влияет на то, останутся ли и будут ли продолжать работать с ним адверты. От техподдержки также сильно зависит количество клиентов и многое другое. Хорошая служба поддержки клиентов не решит всех проблем, которые возникают на тернистом бизнес-пути. Но способна сократить их количество во много раз!

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

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

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

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

Внутренняя кухня

Свои проекты мы делаем по гибкой методологии scrum. Это значит, что в процессе работы клиенту не обязательно придерживаться толстого и нудного ТЗ, а можно добавлять/удалять/изменять любые хотелки прямо по ходу работы. Плюсы: гибкость и прицел на постоянное развитие проекта сразу. Минусы — постоянно неактуальная документация.

Грозовая туча: старые и новые проекты.

Над каждым проектом работает КОМАНДА разработчиков. Это важно, потому что после запуска проекта как минимум два-три человека причастны к коду и могут его поддерживать. На практике это сильно лучше, чем если бы всю разработку делал бы один «незаменимый» гений.

С незаменимостью также помогают бороться две вещи: строгие стандарты кодирования и регулярные code review, которые мы проводим на своих проектах.

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

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

1. Мне нужно ввести нового человека в проект, чтобы он занимался им дальше на постоянной основе.
2. Для развития новичков под присмотром куратора.
3. Очень-очень редко (и рискуя получить за это минусов в карму), но все же: как мера воспитания слишком честолюбивого разработчика с задатками гурмана. Я имею в виду тех редких людей, которые на любую задачу начинают разглагольствовать, что она им не интересна, все технологии — го%но, весь чужой код — вообще го%но и даже свой, который он писал неделю назад — тоже устарел. Он вполне может схлопотать себе на ближайшие 2-3 месяца (или пока не угомонится или пока не станет ясно, что не сработаемся) проекты только на техническую поддержку (это в то время, как его коллеги получают новые, интересные проекты).

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

Итак, мелкие и срочные задачи мы вклиниваем в эти два часа в день, с 16 до 18 (ну фактически, с учетом командной работы это может быть и 4 и 6 часов, в зависимости от того, параллелятся ли задания). Крупные задачи, которые можно делать в спокойном режиме, мы запускаем в работу спринтами (минимум по 40 часов), в основные часы. Работа спринтами стоит для клиента дешевле (в пересчете на стоимость часа), чем экстренные и срочные задачи, которые нужно сделать еще вчера.

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

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

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

Что в идеале хотели бы от нас

1. Получать проактивные предложений по улучшению проекта.
2. Ставить задачу в любой, даже в самой безумной формулировке. Понимания с полуслова. Домысливание «очевидного». Анализа возможных последствий реализации запрошенного. Предупреждения о возможные негативные последствиях и предложение более рациональных подходов. Иногда — заткнуться со своей мудрой аналитикой и делать, как сказали, ибо долго объяснять почему.
3. Ставить задачу через любой удобный канал (скайп, телефон, вотсап, смс-ку). В любое время дня и ночи.
4. Точных оценок.
5. Ответственности за сделанное.
6. Оперативности.
7. Ну и что бы не дорого.

Проактивных предложений по улучшению проекта

1. Бесплатная техническая поддержка наших проектов.
   Это все проекты на этапе ввода в эксплуатацию и в гарантийный период. Это закреплено договором. Поддержка ввода в эксплуатацию (когда менеджер проекта на горячем старте и готов ответить на любой возникающий вопрос у клиента), как правило, это три месяца. Гарантийный период (как правило, это год) — в течение года мы готовы поправить любые найденные клиентом скрытые дефекты, которые не были обнаружены при запуске проекта. Принципиальные различия между первым и вторым в том, что при вводе в эксплуатацию проект находится в «оперативной памяти» менеджера и многие вопросы решаются проще и быстрее. В гарантийном же периоде мы исправляем бесплатно только явные баги. В спорных случаях мы оставляем за собой право, чтобы клиент обосновал нам, почему это баг. Если на диагностику требуется время и по факту баг оказался не багом — мы так же оставляем за собой право выставить счет на затраченное на диагностику время. Формально это честно, но к таким мерам мы прибегаем в единичных случаях, т.к. это создает неминуемо конфликтную ситуацию.
2. Развитие проектов, разработанных у нас.
   Проекты, которые реализовали в нашей компании часто остаются с нами на многие годы. Развиваются и эволюционируют. Обычно мы добавляем новые функции спринтами (от 40 часов). Нам удобнее и дешевле делать один большой блок работ, чем 100500 мелких-срочных задач: экономится время менеджера, меньше рисков допустить ошибки, значительно меньше требуется контроля, и процесс идет более гладко. Однако срочные и мелкие задачи, когда ГОРИТ, клиент не должен накапливать (это плохо для его здоровья). Поэтому такие задачи тоже могут попасть на разработку, но с наценкой за срочность.
3. Проекты, которые делали не мы.
   Мы очень редко берем на поддержку сторонние проекты. Много мелких проектов не соответствует глобальным целям и идеологии нашей компании. Жизнь за счёт саппорта IMHO, более стабильный, но скучный бизнес. Нет драйва и надрыва, что ли. Поэтому сторонние проекты берем крайне редко и неохотно. Критерии здесь такие (перечисляю в порядке приоритета):

• проект должен быть (или потенциально может стать) № 1 или № 2 в своей нише. Или он должен понравиться нам.
• код проекта должен быть грамотным.
• по проекту есть достаточный объем задач.
• клиент адекватно понимает наши принципы и ограничения технической поддержки и принципиально согласен с ними.

Так вот, про проактивность.

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

Ставить задачу в любой, даже в самой безумной формулировке

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

Хочу ставить задачи через любой удобный канал (скайп, телефон, вотсап, смс-ку). В любое время дня и ночи

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

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

Точных оценок

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

Замечу, что работа по time&material на практике для клиента быстрее и дешевле, однако возможна только если клиент доверяет и доволен. Нам это тоже выгодно, т.к. сокращает затраты на менеджмент и бюрократию (а менеджер, напомню, у нас бутылочное горлышко системы).

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

Если вас всерьез интересует вопрос точных оценок — в конце статьи я там насколько ссылок.

Ответственности за сделанное

При схеме time+material по сути все риски лежат на клиенте. Если ошибок много и их исправление выставляют клиенту — он будет недоволен и вам про это скажет. Как правило, экономически выгоднее не вступать в спор и поправить свои ошибки за свой счёт, не нагнетая обстановку, даже несмотря на то, что согласована схема работы по фактическим часам. Я придерживаюсь того, чтобы исправлять ошибки за наш счёт, если:

• проект на поддержке;
• понятно по шагам, как ошибку воспроизвести;
• обеим сторонам очевидно, что это — ошибка разработки (реализации).

Если косяк откровенно наш — берем и исправляем, не компостируя мозги. Так в итоге дешевле.

Исключение: очень сложные системы с большим количеством зависимостей. Поменяешь запятую в карточке товара — сломается какой-нибудь хитрый импорт, который запускается раз в месяц. Здесь либо нужен code freeze + полный тест системы на каждое изменение (что очень дорого), либо полное покрытие кода тестами (что тоже очень-очень дорого), либо смирение, что такие ситуации возможны.

Замечу, что чтобы схема работала — нужно, чтобы спорные ситуации возникали как можно реже. Иначе клиент будет недоволен поддержкой или поддержка будет убыточной для студии.

Еще нюанс — мы не несем на себе ответственность за 3-х лиц (например, хостинг) или упущенную выгоду. Обычно это воспринимается адекватно.

Оперативности

В основном, реальная скорость работы зависит от того, как быстро задача попадет на разработку. Из чего она складывается:

0-8h на приемку и уточнение задачи. Менеджер получает уведомление о создании новой задачи. Банальный деловой этикет и принцип пустого ящика требует, чтобы в течении суток все такие обращения были обработаны. Далее, в зависимости от срочности — задача может быть либо отложена до формирования спринта, либо экстренно запущена в работу, либо запланирована в плане работы на программиста на следующий день. Либо, если формулировки неясны — начинаем работу над выяснением формулировок. Формально, здесь у менеджера есть лазейка включить дурочку и долго-долго чего-то не понимать и уточнять. Однако клиенты это чувствуют и становятся крайне недовольными в таких ситуациях и непременно скажут вам об этом. Останется только разобраться в причинах и применить управляющее воздействие.

8-16h обычно через сутки после того, как задача попала менеджеру проекта и все формулировки понятны, она попадает на разработку. Это связано с тем, что мы планируем, какими проектами будет заниматься каждый программист на утренних планерках (в 8:45) и затем уже стараемся не отклоняться от этого плана. Как правило, задача от клиента попадает в план на разработку на следующий день после постановки (но бывает, что и в тот же день).

16-24h в большинстве случаев мелкие задачи задачи выполняются и отгружаются клиенту за первые 8-16 часов. Еще 8 часов — резерв для выравнивания нашего потока работ или тестирования.

По большим и трудоемким задачам либо формируется спринт, либо — график выполнения, в зависимости от их срочности и приоритетов клиента. Абсолютно непродуктивно делать 30-40 часовые задачи урывками по 2 часа в день.

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

Ну и что бы не дорого

1. обычная, для задач, и которые не горят. Их можно набрать в спринт или делать в рамках нашего графика.
2. срочная (когда «бросаем все, делаем любой ценой»), по двойному тарифу.

Самое важное. Ретроспективы. Разбор полётов

Замечу, что в долгосрочной перспективе бухтение клиента практически неизбежно (ну или я не знаю случаев, когда клиент был бы целиком доволен 2-3 летним итогом поддержки, не имел каких-либо нареканий и время от времени не смотрел бы на сторону). Итак.

Довольно правильно делать с клиентом пересмотр сделанного за 2-3 месяца. Формально анализировать список задач и смотреть причины возникновения ошибок. Это могут быть формулировки, и в этом случае вы совместно должны решить, как вам улучшить постановку задач. Это могут быть слишком частые ошибки программирования, и тут нужно искать причины на своей стороне. Наконец, клиент может быть недоволен тем, что его не отговорили от каких-то его идей и это привело только к лишней трате денег.

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

Без этого в долгосрочной перспективе вас сольют.

Итого

Нажмите на картинку для перехода к интерактивной карте

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

Дайте пользователю надежду на то, что вы ему поможете.

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

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

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

Например, пользователь звонит с обращением «У меня мышка залипает».

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

Попробуем зайти с другого конца: «Итак, у вас не работает мышь, а все остальное на компьютере работает нормально? Например, попробуйте перейти в другую программу при помощи клавиш « Alt » + « Tab » или запустить программу из стартового меню при помощи « Ctrl »+« Esc » и стрелок» .

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

Не стоит выяснять, что пользователь уже делал.

Типичный стереотип, которому подвержены сотрудники техподдержки - 80% проблем пользователей исправляются фразой «А вы пробовали выключить и включить?». Ну да, это часто срабатывает. В то же время, большинство пользователей достаточно хорошо знакомы с компьютером, чтобы проделать такие шаги самостоятельно.

Они отвечают «Да», даже не задумываясь над каждым вашим «Вы уже пробовали…»

Вы пробовали выключить и включить?
- Да

Вы держали нажатыми и , когда нажимали ?”
- Да

Вы держали компьютер над головой, когда выполняли ритуальный танец?
- Да

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

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

Нельзя посадить техподдержку на Linux, если пользователи работают в Windows. Не стоит мигрировать ИТ-отдел на Windows 8, если в компании все еще активно используется Windows XP. Очень важно для сотрудника техподдержки иметь среду близкую к той, что у пользователя на компьютере. Так он может предсказать нормальное поведение компьютера и подсказать пользователю правильные шаги. Рабочая среда компьютера - лучшая подсказка в любых ситуациях, если вы хотя бы примерно знаете, что нужно делать.

Не претворяйтесь, что знаете больше, чем на самом деле

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

Эмпатия

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

Ваша цель сделать пользователя счастливым.

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

Текст пишу в реальном времени, т.е. за этим словом, я даже не знаю какое будет следующее. :)

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

С1.1. Проблематика и отклонения в типовых ситуациях

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

С1.2. Желаемая ситуация

1. Клиент всегда прав. Организация, руководство организации и ее сотрудники являются клиентами службы ИТ.
   1. Ключ к сердцу клиента - факты и цифры, показывающие динамики и позволяющие делать прогнозы, чтобы принимать решения.
   2. Все люди, белые и черные, принимают решения одинаково (за исключением клинических отклонений в развитии разума и закрытие в дурдоме). Разность лишь в исходной информации. Умение подобрать нужную информацию - это основа успеха и понимания.
   3. Сбор нужной информации это один из результатов правильной организации поддержки.
2. Нужно получить доверие пользователей
   1. Они должны быть уверены в том, что сообщив один раз свою мысль, она будет записана, рассмотрена, будет ответ или решение. А не игнорирование или "а я забыл".
   2. Первая фраза человека достигшего состояния Будды: я это ты. Если вы видите перед собой тупого человека... задумайтесь. Это не шутка.
   3. Начинается все с записи обращений, но затем списки (базы данных, реестры, справочники) расширяются с развитие всей системы.
3. Порядок - дело тонкое
   1. Результат службы ИТ это наличие нужной информации у сотрудников и отсутствие простоев в их деятельности. Но это лишь слова. Понять это сложно и понимание этого приходит лишь после некоторого времени использования системы управления ИТ.
   2. Справедливость штука сложная. Для ее понимания есть отдельная статья и она
   3. Кто у руля ИТ? Руководитель или специалист? Есть очень простой тест: ведется у вас регистрация обращений пользователей? Если - да, то у руля или руководитель или человек подающий надежды, если - нет, гнать нужно этого руководителя в шею, или понижать до специалиста, пусть даже ведущего.
   4. У любого действия должен быть приоритет... и в первую очередь должны выполняться те действия, которые дают больший эффект с точки зрения целей организации. Добиться этого не просто, но реально.
4. Режем издержки
   1. Простои минимизируем любой ценой, кровь из носу, т.к. любой простой это не просто "ща ща починим", это последствия, которые не всегда можно отследить, снижение репутации, потери клиентов и т.д.
   2. Сбои нужно записывать, выслеживать причины, причины устранять - повторяющийся сбой это позор джунглям.
5. Ну а выполнив эти 4 пункта, приходит понимание, что ИТ - это ИТ, и им уже сотни тысяч лет... а комьютеры - это компьютеры им всего-то лет 50 и сейчас они используются чаще, чем стены пещер лишь потому, что чуть-чуть эффективней и не более того:)

С2. Особенности

1. Ключевой факто успеха это регистрации всех обращений пользователей. Ключевое слово в этом предложении: всех . Начнешь халтурить и пропускать обращения - пошел вон, ты не руководитель.
2. Когда добьешься регистрации всех обращений, то система начнет развиваться... сразу становятся заметны узкие места:
   1. нет инструкций по процессам или инструкции кривые - много вопросов
   2. нет обучения сотрудников - много вопросов
   3. оборудование или программы слабо настроены или плохо подобраны - много сбоев
   4. специалисты занимаются чем попало, но не тем, что нужно для организации, а значит и для руководства.
   5. если проект какой-то плохо выполните, то динамика обращения подпрыгивает... надо проекты лучше планировать...
   6. ну, в общем картинка становится ясная и в голове сразу появляется множество идей о том как улучшить ситуацию...
3. Очень важный элемент системы это CMDB или КБД - конфигурационная база данных или объекты услуг:
   1. Здесь указываются все объекты, которые попадают под сферу влияния ИТ, для того, чтобы отслеживать те действия, которые над ними выполняются.
   2. Частота сбоев по программам... что чаще вызывает сбои 1С БП 8 или 1С БП 7.7? Как следствие кто из них вызывает больше затрат?
   3. Какие изменения и кто выполнял в программах? В каких? Пришло время перехода на новую версию? Какие изменения стоит повторить, а какие нет? Сколько это по финансам? Тут ответы находятся в лет.
   4. Кто то пытается сюда же пихать мышки и сетевые карты... это личное дело каждого и каждый сходит с ума по своему... но мой опыт показывает, что такая детализация дает много затрат и мало толку и по сути это мартышкин труд.
   5. В основном если вы отвечаете за ИТ, то достаточно вести учет в разрезе программ, баз данных, модулей системы, а компьютеры ваще можно записать как Компьютеры, даже без детализации по кабинетами, не говоря уже о детализации по комплектующим)
   6. А если вы отвечаете еще и за качество (это уже ИСО 9000), то сюда же можно внести перечень всех инструкций и регламентов регулирующих и нормирующий порядок действий сотрудников. В этом случае руководство на вас уже молиться начнет, свечки в церквях ставить за ваше здоровье. Это не считая прочих бонусов и соц.пакетов))

С3. Варианты решений

1. Рассмотрим для начала характеристики обеспечивающие качество ИТ
   1. Основные, обязательные, которые нужно выполнить в первую очередь
      1. Запись обращений, даты приема, даты завершения, еще можно результат фиксировать
      2. Регулярный (ежедневный, еженедельный, ежемесячный) мониторинг показателей, загрузки, результативности, динамики...
   2. Дополнительные, удобные, улучшающие, можно выполнять во вторую очередь
      1. Запись изменений, проектов, объектов услуг для дополнительных разрезов анализа
      2. Ведение истории общения по обращениям, автоматические рассылки уведомлений на эл.почту обратившимся.
2. Инструменты
   1. 1С ИТИЛИУМ
      1. Плюсы
         1. Основные требования тут выполнены
         2. Можно изменять ПО
         3. Можно найти пиратку
         4. Есть настройка автоматических уведомлений о создании
         5. Сильная отчетность
      2. Минусы
         1. Историю переписки вести тяжело, нет уведомлений о комментариях на эл.почту или возможности отвечать письмом
         2. Веб-морда тяжелая
      3. Рекомендации
         1. Для безденежных пиратов
         2. Тем, у кого политика привязана к 1С
         3. Тем, кто любит ковырять программы и любит 1С
      4. Цена что-то около 50 т.р. за ПО, услуги добавляются по вкусу.
      5. Заметки
         1. мне нравится т.к. это была моя первая система на которой построил управление ИТ
   2. eStreamDesk - одно из наиболее эффективных решений
      1. Плюсы
         1. веб-ориентированная и модель SaS, т.е. доступ из любого места и не надо парить голову с правильной установкой и тех.поддержкой
         2. интегрирована с Google Apps
         3. есть русский язык
         4. есть конструктор автосообщений как при добавлении и закрытии обращений, так и о переписке по ходу решений;
         5. реально пользоваться даже бесплатным вариантом
      2. Минусы
         1. кривоватый код, глюки и плюшевой интерфейс
         2. отсутствует CMDB
         3. слабая отчетность
      3. Рекомендации
         1. для малых проектов, там где есть проблемы с финансами
         2. и если нет юридических отношений, т.к. у обращенцев нельзя указать организацию
      4. Цена от 0 до см. сайт. Услуги тут если и нужны то по минимуму т.к. функционал базовый.
      5. Заметки
         1. им бы код до ума довести, отчетность гибче и возможность ведения базы пользователей по организациям - было бы клево.
   3. Mojo HD
      1. Плюсы
         1. те же, что и у п.2, но более приятный, отлаженный интерфейс и русификация чуть сложнее
         2. отчетность хорошая
         3. гибкий конструктор уведомлений о изменениях, комментариях...
         4. возможность отвечать на эл.почту
         5. ведение базы пользователей по организациям
      2. Минусы
         1. русского языка нет, но весь интерфейс можно переписать хоть на грубый мат
         2. цены относительно кусачие, бесплатным вариантом пользоваться не реально
      3. Рекомендации
         1. для устойчивых проектов, с наличием стабильных финансов
         2. тем, у кого нужно вести клиентуру по организациям
      4. Заметки
         1. цены чуть потише и можно считать идеальной системой для внутренних служб и проф.бизнесов
   4. ДИРЕКТУМ
      1. Плюсы
         1. Есть выделенный модуль IT.Now но с заточкой под мышки. Нарушение принципа С1.1. п.5. Что-то типа 1С ИТИЛИУМ, но мене гибкий и похуже.
      2. Минусы
         1. Те же, что и у 1С ИТИЛИУМ
         2. Выделенного и продуманного модуля в части ИСО 20000 - нет. 1С ИТИЛИУМ перекрывает возможности в лет.
      3. Рекомендации
         1. Можно написать свой модуль... что оправдано в сложных ситуациях... например в гос.управлении и в гос.услугах, там где практика еще не наработана, но нужна интеграция с большим бумажным документооборотом.
      4. Заметки
         1. ДИРЕКТУМ хорошая система ЭДО, и построение ИТСМ на ее базе оправдано лишь в том случае если на этой системе строится все остальное. как уже было сказано например в гос.управлении.
   5. 1С ITIL чего-то там от Рарус
      1. Плюсы
         1. это 1С
      2. Минусы
         1. сама программа написана теми, кто полностью подчинен стереотипу из С1.1. п.5. ориентирована на учет мышек и микросхем, вместо контроля характеристик по процессам.
      3. Рекомендации
         1. Для тех у кого нет сил сломать свои стереотипы и вместо ИТ хочется и дальше заниматься компьютерами да программами.
      4. Заметки
         1. Рарусу самим тех.поддержку нужно выправить. потом уже другим решения предлагать.
         2. субъективно меня чуть не стошнило при изучении этой программы.
   6. HP, IBM и иже с ними
      1. большие и сложные, скорее всего ориентированы на большие объемы обращений.
      2. может быть интересны для таких монстров как Мегафон или Билайн, там где толпы пользователей.
      3. слышал, что Газпромовцы такие решения покупают. наверное там откаты вкусные.
   7. Naumen ServiceDesk коробка
      1. не видел, но чую, что интересно.
   8. Naumen ServiceDesk SaS
      1. Скоро обещают выпустить.
      2. Учитывая опыт Наумен решение должно получиться интересным.
      3. Если они выберут ценовую политику как у Мегаплана, то я их даже наверно постараюсь полюбить.
      4. Очень надеюсь, что тут получится аналог Можо ХД (п.3), но с ценовой политикой как у Мегаплана.

С4. Резюме

1. Кто владеет информацией тот владеет миром. Это не шутка. Нетократия уже рядом.
2. Но чтобы владеть информацией, нужно управлять ИТ. А не просто компьютеры отверткой крутить да пасьянсы в 1С программировать.
3. В комментах можно задавать вопросы... постараюсь даже на них отвечать.
4. Все что тут написано это эмпирические отражения субъективных мыслей... кому будет полезно - пожалуйста, кто считает иначе - ваше право.

С5. Просьба

1. Кто и какие еще инструменты управления ИТ знает? Особенно интересует категория SaS и возможность авторассылки уведомлений для пользователей на эл.почту...
2. Ну и вообще буду благодарен за дополнения, замечания, критику... может я где то ошибаюсь или моя информация уже устарела?

С6. Копирайты

1. Наши группы на Инфостарт (заброшены правда, т.к. от 1С сейчас слегка отошел, чуть другими проектами занимаюсь)
   1. Инструкции и регламенты для 1С Предприятие
   2. Технология внедрения 1С Предприятие
2. Обещанная ссылка на управление проектами