Help Desk Software *

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

В этой статье хотелось бы поделиться мыслями, какой софт и когда имеет смысл покупать для IT компании.

Итак, наступила середина июня, пандемия в России существенно замедлила свое распространение, карантинные мероприятия по всей стране постепенно отменяются и, по моему ощущению, пришла пора обобщить приобретенный опыт и, самое главное, сделать какие-то выводы на будущее.

Я работаю консалтинг-директором в компании ОНТЕК, мастер-партнере Zendesk в России. Мы проектируем, внедряем и поддерживаем системы управления продажами, поддержки клиентов, взаимодействия с клиентами в мультиканальных средах (колл-центры, сайты, социальные платформы).

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

Здравствуй, уважаемый %habrauser%. Около 3 лет назад я написал статью о том Как я создал систему установки принтеров на работе. Не могу не согласится с комментариями и отзывами от прошлой статьи, гласящие о том, что для установки принтеров можно воспользоваться групповыми политиками, но в мире в enterprise, больших или малых, возможны и другие случаи разного характера когда не смотря на наличие домена и групповых политик не представляется удобным\возможным разворачивать принтеры через GPO-шки. Учитывая собранный опыт и отзывы пришло время показать о моей новой переписанной системе с гораздо большим и удобным функционалом с сохранением минимализма, и я надеюсь, что кому-то она пригодится. В статье я также расскажу о том, с какими трудностями я столкнулся при создании этой системы. Кому стало интересно добро пожаловать под кат. Осторожно! Будет много картинок!

FSM и наша жизнь

Добрый день! Я — Дарья, продуктовый аналитик отечественной service desk системы, и хочу рассказать о том, что такое Field Service Management.

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

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

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

Управление рабочими станциями при их физическом отсутствии в офисе — новый вызов для компаний, которые перевели сотрудников на удалённый режим работы. При наличии прав администратора, пользователи, непреднамеренно могут установить софт, который окажется эксплойтом для чьего-то злого умысла. Например, многим известен кейс отказа от Zoom в Google, SpaceX и других известных компаниях и государственных структурах.



В этой статье мы разберём примеры использования решения для распространения ПО и инвентаризации Quest KACE в том числе и для обнаружения на рабочих станциях того же Zoom. Подробности под катом.

В эпоху бурного развития SaaS отсутствие личного кабинета для облачного сервиса уже считается просто неприличным. Но для сервисов защиты от ботов и других киберугроз есть еще одна важная причина: они не похожи на такие популярные сервисы, как облачные хранилища (типа Azure, AWS), аренда виртуальных серверов (DigitalOcean) или система контроля версий (GitHub, Gitlab) по той причине, что клиентам здесь часто трудно понять, за что именно они платят деньги. Только продвинутая статистика и наглядные графики могут четко ответить на этот вопрос. Поэтому у процесса создания личного кабинета в Variti были свои особенности.

В новой редакции ITIL Service Desk занимает ключевую позицию в цепочке создания ценности компании. Служба поддержки — единая точка контакта поставщика ИТ-услуг с пользователями. Качество работы службы отражает качество предоставления услуг, а значит, непосредственно влияет на репутацию поставщика.

Обозначим основные изменения в подходе к Service Desk с точки зрения авторов ITIL 4.

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

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

Напомню, что с вами на связи продуктовый аналитик отечественной service desk системы HubEx. В этом материале я продолжаю рассказывать про опыт нашего клиента, крупной сервисной компании «Брант». Одна из постоянных «болей» при оказании услуг — штрафные санкции со стороны клиента, в этом материале мы расскажем о том, как их избежать. И подскажем сервисным коллегам другие полезные советы, которые остановят руку кризиса.

С 16 марта наша команда ITSM 365 начала тестировать полноценную удаленную работу. Наши офисы в Екатеринбурге, Москве, Твери, Питере постепенно пустеют. Но мы, «переехав» домой, продолжаем оттачивать дзен при техподдержке клиентов и без паники решать другие рабочие вопросы.

Вместе с тем, оторвавшись от офисного пространства, все корпоративные сервисы от внутренних служб (ИТ, HR, бухгалтерии и других) получаем удаленно. Пришла пора протестировать, как это работает!

Пока мы еще на старте, поэтому хочу зафиксировать «как сейчас», а через какой-то период чекнуть, «что потом».

Год назад компания Axelos представила четвёртую версию ITIL, библиотеки лучших практик управления ИТ-услугами. Один из ключевых её разделов посвящён руководящим принципам ITIL 4 (The ITIL guiding principles).



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

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

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

Как раз в «Основах», первой из семи книг новой библиотеки, подробно изложены руководящие принципы ITIL 4. Базируются они на известных методиках: Agile, Lean, DevOps и т. п. То есть guiding principles помогают интегрировать лучшие практики в единый подход к управлению ИТ-услугами.

Снова на связи продуктовый аналитик отечественной service desk. В прошлый раз мы рассказывали про нашего клиента, сервисную компанию “Брант”, которая внедрила нашу платформу во время активного роста своего бизнеса.

Одновременно с ростом числа заявок у “Бранта” выросло и число объектов обслуживания — количественно и территориально. Как следствие, понадобилось больше разъездов на большие расстояния, и бюджет на расходы по ГСМ значительно увеличился. Как автоматизация диспетчерской службы помогла уберечь ее от этих расходов, хочу рассказать в этом посте.

Меня зовут Дарья, я продуктовый аналитик. Основной продукт моей компании — service desk, облачная платформа, которая автоматизирует бизнес-процессы: например, ремонтные работы, техническое обслуживание различных объектов. Одна из моих задач — участие в процессе внедрения нашей платформы в бизнес клиентов, при этом нужно погрузиться в специфику работы конкретной компании как можно глубже.

Хочу поведать, как удалось автоматизировать трудоемкие бизнес-процессы одному из наших клиентов, сервисной компании “Брант”. Компания обратилась к нашей платформе, когда количество ее клиентов, и, соответственно, заявок на обслуживание, стало стремительно расти. Бизнес активно развивается, ведь это отлично, в чем подвох? В том, что резко растет и количество однотипных рутинных процессов, и эту опасность нельзя недооценивать. А кроме того, становится очевидно, что нельзя пользоваться теми же инструментами, которые работали, когда заявок было меньше.


Знакомо?

Итак, история спасения.

В каждой техподдержке свои процессы, тикет системы, принципы коммуникации с клиентами. Объединяет эти сервис службы – стремление бороться с пожирателями времени.

Когда в десятый раз за день в рабочем чате видишь «Не помнишь, как по такой заявке лучше ответить?», «Где лежит инструкция?», «Кинь ссылку, не могу найти», а в параллель коллега с порога «Не занят? Мне только спросить», начинаешь взывать к богам, которые хоть что-то слышали про Knowledge Management.

И все чаще мечтаешь не о новом мониторе в 49 дюймов, а о Базе знаний, да лучше с продуманной структурой, удобной навигацией и интеллектуальным поиском. И, пожалуйста, если можно, пусть это будет не склад папок на FTP и не портянка ссылок в Google Docs!

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

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

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

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

Кажется, что от этого не уйти, потому что техника есть техника: что-то ломается, теряется, портится… Но мы нашли неожиданное решение, как уменьшить нагрузку на хелпдеск и предельно сократить время ожидания нового аксессуара для сотрудников.

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

Бесплатный софт для бизнеса — спорная история. Компания, которая выбирает такое ПО, должна понимать, что либо ей придётся столкнуться с open source и искать разработчика на поддержку программы, либо принять бесплатную версию программы как есть, без надежды на поддержку, доработку и обучение. Так себе перспектива. Но это с позиций околоайтишного обывателя, который слова «open source» и «вендорское внедрение» выучил, а глубоко не погружался. А мы вот взяли и решили растолковать всё на примере одного популярного ПО, которое может пригодиться и большим, и маленьким компаниям. Давайте разбираться вместе.


Морали не будет, а вот выбор есть

Вот представьте, купили вы автомобиль, что вы будете делать? Своевременно проводить ТО, искать АЗС, где нет палёного бензина, мыть, полировать, покрывать воском  и всякими там нано-растворами и защищать сигнализацией — ну это если вы в здравом уме. Вряд ли вам придёт в голову бояться его заводить и только любоваться, заливать масло подешевле, купленное на трассе, затягивать его в пищевую плёнку, забивать на поломки до полного отказа тормозов и оставить защитную систему на потом. Логично? 

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

А вы — любите свой бизнес?


Источник. Думаете, вискарь? Ан нет, валерьянка!

Как я уже писал в статье 7 основополагающих принципов ITIL, 4 аспекта управления услугами ITIL заслуживают отдельной статьи.

Для тех кто знаком с ITIL v3, эти аспекты покажутся знакомыми. В книге «Service Design», было описание 4P (the 4P of Service Design) проектирования услуг: Продукты (Products), Процессы (Processes), Персонал (People), Партнеры (Partners/Suppliers). Сейчас ITIL предлагает опираться на данные аспекты на всем жизненном цикле создания продукта или услуги, конечной целью которых является создание ценности (value).

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

Duran (вроде бы)