в течении какого срока после решения инцидента в help desk надо оценить и закрыть инцидент

Работа с инцидентами информационной безопасности

Доброго дня, уважаемый хабрахабр!

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

Информирование об инцидентах

Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:

1. Helpdesk.
Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.

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

3. Инциденты, обнаруженные сотрудниками ИБ.
Тут всё просто, и никаких телодвижений для организации такого канала приёма не требуется.

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

Категорирование инцидента

Хоть инциденты безопасности разнообразны и многообразны, их довольно легко разделить на несколько категорий, по которым проще вести статистику.

1. Разглашение конфиденциальной или внутренней информации, либо угроза такого разглашения.
Для этого необходимо иметь, как минимум, актуальный перечень конфиденциальной информации, рабочую систему грифования электронных и бумажных носителей. Хороший пример — шаблоны документов, практически на все случаи жизни, находящиеся на внутреннем портале организации или во внутренней файлопомойке, по умолчанию имеют проставленный гриф «Только для внутреннего использования».
Немного уточню про угрозу разглашения, в предыдущем посте я описывал ситуацию, когда документ с грифом «Только для внутреннего использования» был вывешен в общем холле, смежным с другой организацией. Возможно, самого разглашения и не было (вывешено было после окончания рабочего дня, да и замечено было очень быстро), но факт угрозы разглашения — на лицо!

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

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

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

5. Компрометация учетных записей.
Этот пункт перекликается с 3. Фактически инцидент переходит из 3 в 5 категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.

Классификация инцидента

С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.

Сбор свидетельств инцидента

Есть особенная прикладная наука — форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика — компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.

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

После устранения инцидента

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

• переоценка рисков, повлекших возникновение инцидента
• подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента
• актуализация необходимых политик, регламентов, правил ИБ
• провести обучение персонала организации, включая сотрудников IT, для повышения осведомленности в части ИБ

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

Несколько советов

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

Источник

Управление инцидентами в IT может быть не только про IT

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

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

Ссылка на оригинал
Опубликована 15.01.2018.
Сложность: начальный уровень (идеология)

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

Что такое инцидент?

Наиболее популярный сейчас в мире сборник практик по управлению ИТ услугами — ITIL даёт такое определение инцидента:

«Незапланированное прерывание ИТ услуги или ухудшение качества ее предоставления…»

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

Мой клиент же определяет инцидент по другому. Инцидент — это

«любое отклонение продукта бизнес процессов в сторону нежелательного для бизнеса результата.»

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

Кто может предложить действие для решения инцидента?

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

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

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

Когда закрывать инцидент?

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

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

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

Какие отчеты об инцидентах создавать?

Обычно отчёты управление инцидентами сосредоточены на том, как быстро ИТ организация решает инцидент. Это может быть полезным при планировании и управлении совершенствованием ИТ и показывает, на сколько выполняются обязательства перед заказчиком по уровню обслуживания услуги (Service Level Agreement, SLA). Но для бизнеса такой подход ценности практически не несет.

Когда Вы переопределите инцидент на более “бизнесовый” вариант, то с большей вероятностью будете создавать отчётность, несущую ценность для бизнеса:

Заключение

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

Источник

Как я искал хелпдеск среди 15 решений и… не нашёл

Этой статьи не должно было быть: вроде как и Хабр не жалобная книга, и у меня частная история далеко не хабровской компании. Но именно на Хабре я получил не очень корректное отношение одной компании и познакомился аж с двумя другими в самый подходящий момент — в момент, когда я искал хелпдеск. Я протестировал и перебрал 15 разных хелпдеск-систем и не смог выбрать из них ни одну! Уже прочувствовали всю драму? Рано! В общем, я перекипел, выпустил пар, заставил потестировать своих коллег, немного выдохнул и решил не бомбить на эмоциях, а написать текст — о том, как требования могут соотноситься с ПО и о том, что разработчики иногда несколько оторваны от реальности. Хотя без эмоций не получится, потому что я был по обе стороны софта: и заказчиком, и разработчиком, а значит, понимаю обоих. Но никого не хочу оправдывать. Простите, если будет лонгрид. Может и лонг, но зато экшен!

Итак, что случилось

Некоторое время назад я устроился в компанию на должность технического директора. Компания занимается продажей и обслуживанием медицинского оборудования (не самого сложного, но распространённого), работает напрямую с множеством частных клиник, косметических кабинетов, студий, стоматологов и проч. Никаких особенных секретов в этом бизнесе нет, и в принципе ребята обходились услугами приходящего сисадмина, но некоторая смена бизнес-процессов заставила обрести продвинутого специалиста для контроля и поддержки работы CRM-системы, собственного сервера, IT-парка сотрудников, 1С (я плакал и отбивался) и проч. инфраструктурных штук. Особенно остро стояли три проблемы, которые имеют очень важное значение для этой статьи.

Короткий список из 11 лучших систем с рекомендацией, для кого они — внизу.

Можно всех посмотреть?

Бесплатно, то есть… недаром

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

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

Форма заведения тикета в Freehelpdesk

osTicket — open source, весьма скромная функциональность и звание «самой популярной в мире программы для поддержки клиентов» (what?!). Но есть облако, которое вычёркивает хелпдеск из этого раздела: облако платное и стоит от 9$ на человека в месяц. В опенсорсной версии много ограничений, без танцев с бубном работать не получится.

Окно с тикетами и быстрым просмотром тикета в osTicket

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

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

Вендорские платные решения

«А вот тут разгуляться!», — подумал я и, конечно, зря. Я и моя команда в составе двух человек тестировали эти системы, анализировали профили работы, общались с вендорами в течение 2 месяцев. Я бы мог многое рассказать о нюансах общения — например, как девушка бросила трубку, узнав, что «прямщас-не-купим», как менеджер врал про цены, как профессионально культурно и слаженно работают менеджеры Terrasoft (ой, я это вслух сказал), какая классная цепочка писем у Okdesk (правда, от неё устаёшь уже пока выбираешь, регайтесь на левые почты), насколько конкретен и лаконичен разговор с инженерами ZEDLine Support (никаких продажников на меня не напало), как душевен консультант ITSM 365 (от Наумена ждёшь скриптов) и как много вендоры привирают про свои продукты 😉 И да, я помню всех, кто не перезвонил.

ITSM 365. Так получилось, что с этой системой я довольно давно знаком как пользователь и системный администратор, поэтому сюрпризов было мало. Мне всегда нравилось, что есть клиентский портал, а это одно из моих основных требований, есть конкурентные лицензии — для посменного саппорта отличный способ сэкономить. Это хорошая ITSM-система, которая помогает управлять ИТ-активами и немного хуже — всем остальным. Судя по анонсам, скорой выйдет версия Customer — рассчитываю её увидеть ещё до того, как мы что-либо внедрим. Но это Naumen, а Naumen — это дорого. Впрочем, о ценах я напишу ниже.

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

Service Creatio — бывший bpm’online, а до этого Terrasoft, и у меня нет повода не доверять этой компании. Хорошая система, которая представляет собой хелпдеск, «натянутый» на лучшие паттерны CRM-системы. В карточке инцидента используется исчерпывающая информация, можно настраивать нормативное время реакции, считать затраты времени, есть возможность настройки очередей с правилами и шаблонами и т.д. Если бы можно было давать места в моём обзоре, я бы дал Creatio первое место.

Так почему вычеркнул, если понравилось? Мы хоть и занимаемся мед. оборудованием, зубы по 27 тыщ за кариес не лечим, поэтому являемся малым бизнесом. И нам дорого. 1630 р. на пользователя в месяц — чем дороже остальных?! Но Terrasoft ещё со времён декстопного CRM славится дерзкими игрищами с ценовой политикой, ставит * и… начинается. Короче, стоимость минимального стартового пакета для новых клиентов составляет 2500 USD, курс привязан к валюте, поддержка очень платная, внедрение очень платное, контракт нужно заключать сразу на год и никаких тебе скидок + если большой объём работ, придётся платить за расширение дискового пространства и т.д. То есть в первый месяц вынь да положь минимум 200-250 тыс. руб. Для кого-то это вся выручка. Не знаю, если вы очень большая компания — присмотритесь, если маленькая, идём дальше, там интересно.

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

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

Почему вычеркнул? Эта система стояла первой к покупке в моём рейтинге, но некоторое общение на Хабре, игнор личных сообщений с важными подробностями и отрицание поведения своего менеджера (грамотного и клёвого, но облажавшегося в паре моментов) заставили меня задуматься — а как они поведут себя со мной в дальнейшем. Ну и да, для меня система слишком перегружена, не хочу платить за квази-CRM, мне своей хватает. Пусть я субъективен, но по совокупности — нет.

IntraService — всё, что я хочу сказать об этой системе, так это то, что портал создавался час и не создался, потом 15 минут и только с третьего раза минуты 3-5. При этом стабильность соединения и скорость не менялись. Ну как так-то?

Но я парень упорный, и протестировал функциональность. Мне показалось, что она больше заточена под запросы на доработку со стороны вендора. Форма заявки перегруженная (12-15 полей), окно заявок перецвечено (хотя очень быстро привыкаешь ко всем этим цветам и обозначениям, для саппорта а-ля колл-центр очень неплохо). Понравились фильтры для выбора заявок (27 критериев фильтрации), предпросмотр заявки, выгрузка в Эксель (аккуратно), API.
Почему не выбрал? Ну это просто не то, что мне нужно + не понравилось моим коллегам. Для кого-то вполне компромиссный вариант. Судя по сайту и диалогами с менеджерами, компания не изобилует клиентами. Иногда таких стоит выбрать хотя бы потому что у них будет время с вами возиться. Но за такую цену есть интересные решения из вышеописанных.

HelpDeskEddy — к этому моменту я заигрался в Шерлока Холмса, а тут такое!

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

Обычно я проскакиваю маркетинговую шелуху, но тут я увидел среди клиентов Lamoda, L’Oreal, mail.ru, ВТБ, Delivery Club. Неужели реально у этих компаний так организован хелпдеск? Провёл расследование с помощью СБИС и TAdviser, почитал источники, изучил финансы. Выяснилось, что компания занимается индивидуальной заказной разработкой, в том числе для банковской сферы. Как я понял, сам хелпдеск это далеко не основной продукт.

Почему не выбрал? Мне не понравилась логика формирования всех заявок как почтовых сообщений.

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

Почему не выбрал? Это однозначно не хелпдеск и тем более не CRM, это какой-то омниканальный сборщик. Наверное, такое решение подойдёт какому-нибудь В2С из малого бизнеса. В общем, инструмент сбора и хранения диалогов и обращений по ним, но никак не профильное ПО.

Юздеск похож по логике на предыдущий сервис, но более сервис-ориентирован, с показателями SLA (мониторинг качества обслуживания, что неплохо) и элементами тикет-системы. Есть правила обработки заявок, есть шаблоны. Фишка — максимум простой интеграции с другими сервисами. Проект Сколково, грешат инфобизнесом 😉 Я бы сказал, что это простое и оптимальное решение для SMM-задач компаний разного масштаба.
Почему не выбрал? Совсем не тот профиль.

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

Компании с Хабра

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

ZEDLine Support — молодая система, которая, как ясно из блога, разработана командой RegionSoft CRM. Учитывая, что CRM-системе много лет, меня порадовало, что разработчики, скорее всего, не стартаперы со смузи и в горчичных штанишках, то есть меня не макнут в красивый интерфейс и ноль за ним, как у многого новодела. Так и оказалось, но тут я испытал противоречивые чувства.

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

Почему я не выбрал? Мне пока неясно, каким будет API у ZEDLine. Плюс ко всему, мне хочется какой-никакой интеграции с моей CRM-системой, а у них пока есть только интеграция со своей RegionSoft CRM. Из приятного — есть интеграция с виртуальными АТС.

HubEx — как я понял, тоже молодая система. Они меня привлекли сразу тем, что географически близки для меня и можно было бы провести какое-то даже очное обучение или пообщаться в офисе. Но не стоит спешить, правильно? Я предпочёл тестовые прелюдии. Скажу сразу: система интересная, конкретно заточена под сервис. То есть если выше я плакался про ITSM, то здесь никакого ITIL, только сервис-сервис.

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

Участники одним списком

Что же я такого хотел, что меня не устроил никто?

Это я ищу хелпдеск

А вот прямо ничего сложного.

Цены на сладкое

Итак, мне нужна была система без мобильной версии на 17 операторов. Я выбрал наиболее подходящие по функциональности тарифы, сопоставимые с моими целями. Разброс цен вышел таким каким вышел — вы можете видеть его в таблице. Должен отметить, что некоторые компании предложили скидки по разным причинам. Так, например, HelpDeskEddy указал на сайте, что при оплате за год нужно платить только за 10 месяцев, а ZEDLine Support при оплате за год даёт 15% скидки. Ещё одна компания предложила скидку 20%, но говорила, что это закрытая тема (ага, по секрету всему свету), не буду публично заявлять. А вывод, знаете, какой? Спрашивайте!

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

Не буду судить об адекватности цен, но в целом почти у всех считаю их разумными. В любом случае, инвестировать в хелпдеск и тикетную систему — это инвестировать в интенсивный рост. Скоро я вернусь к этой задаче 🙂

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

Источник