Каждый день к нам приходят сервисные компании, управляющие штатом мобильных сотрудников и подрядчиков, с задачами оптимизации сервисных процессов на базе нашей ИТ-платформы HubEx. Чтобы помочь определиться с целями внедрения и системно ступить на путь автоматизации сервиса, и подготовлен данный материал.
База знаний используется для обмена знаний и управления. Основная цель наличия базы знаний - предоставить как вашим клиентам, так и вашей команде наиболее подробную информацию о ваших продуктах / услугах и ответить на все их общие вопросы. Поэтому их часто называют порталами самообслуживания.
В зависимости от основного варианта использования базы знаний могут быть общедоступными и доступными для всех или частными. Частные обычно создаются для внутреннего использования внутри команды.
Теперь, как именно можно использовать базу знаний? И каковы преимущества его наличия? Вот лишь некоторые из преимуществ, которые вы получаете, выбирая лучшее программное обеспечение для управления знаниями:
Одной из задач систем ИТ-мониторинга является сбор, хранение и анализ различных метрик, характеризующих как состояние различных элементов ИТ-инфраструктуры (загруженность CPU, объем свободной оперативной памяти, объем свободного дискового пространства и т.п.), так и состояние различных бизнес-процессов. Для того чтобы применять обширный математический аппарат статистического анализа, эти данные часто удобнее представлять в виде упорядоченных временных рядов соответствующих переменных. Хорошим инструментом для обработки временных рядов в языке Python является комбинация трёх модулей: pandas, scipy и statsmodels (pandas.pydata.org, scipy.stats, statsmodels.org), которые предоставляют широкий набор классов и функций для построения временных рядов, для оценки множества различных статистических моделей, а также для проведения статистических тестов и исследования статистических данных. Из всего содержащегося в этих модулях математического паноптикума, конкретно в данной статье, будет описаны алгоритмы, в частности корреляционный анализ временных рядов метрик ИТ-инфраструктуры, которые мы применяем для root cause анализа в AIOps платформе monqlab.
Количество самого разного оборудования во всём мире неуклонно растет. Не последнюю роль в этом играет развитие промышленного интернета вещей (Industrial Internet of Things, IIoT) и повсеместное проникновение “умных” устройств: датчиков, контроллеров и т. д. Согласно прогнозам уже к концу 2020 года количество “умных” устройств в мире превысит 200 миллиардов. Вся эта "армия" оборудования, несмотря на возможности удаленного управления, требует профилактического и выездного обслуживания (Field Service Management, FSM).
Расскажем об основных правилах повышения эффективности выездного обслуживания. Их 7.
Приветствую всех. С кем не знаком - Андрей Балякин: 7 лет в сервисном бизнесе, 20 лет в ИТ. Предприниматель. Последние несколько лет - CEO проекта HubEx (ИТ платформы автоматизации выездного обслуживания и управления сервисными процессами).
Цель публикации - собрать мнения и всесторонний опыт тех, кто внедрил какие-либо системы для управления выездными сотрудниками в своей компании и готов поделиться опытом с остальными.
Если у Вас был опыт общения с руководителем отдела технической поддержки, то наверняка первое, что Вы от него услышали это многочисленные жалобы на жизнь, сотрудников и жестоких клиентов.
Управлять небольшой службой техподдержки из 5 человек еще как-то можно, но когда людей становится больше, а количество обращений в день переваливает за сотню, то жизнь руководителя превращается в ад: постоянные эскалации, перегруженность персонала и почти полная утеря контроля за происходящим.
Просто представьте, что у Вас сотня админов, которых Вы ежедневно обеспечиваете работой (это не выдумка, а реальность).
В этой ситуации надо что-то предпринимать. Тут каждый выкручивается как может – выдумываются многочисленные отмазки, изобретается «стандартизация», клиентов заставляют заполнять невероятных размеров формы с полями, назначение которых невозможно угадать, а при каждом удобном случае обращения скидываются с исполнителя обратно на клиента. На нарушения SLA (плановых сроков исполнения заявок) вообще никто не смотрит. Перечень мер можно продолжать бесконечно.
Проблема не нова и не уникальна – она присутствует на каждом предприятии, в какой бы области оно ни работало. Перепроизводство, перегруженность персонала, проталкивание срочных заказов. Аналогии напрашиваются.
Можно ли с этим что-то сделать? Конечно! Работающие и очень эффективные меры давно известны – это Бережливое производство (Lean Manufacturing) и Теория ограничений (Theory of Constraints, TOC).
Давайте посмотрим как методы и метрики бережливого производства могли бы послужить на благо службы технической поддержки Вашей компании.
Lean – это бережливое производство. Насколько его философия и рекомендации применимы в сфере управления ИТ-услугами? Может ли управление интеллектуальным и высокотехнологичным производством быть бережливым и как на практике применять принципы Lean для ИТ?
Основная идея Lean, или бережливого производства, – максимальная польза для потребителей с использованием минимальных ресурсов компании-производителя. Цель Lean – это организация работы, при которой можно избежать финансовых, временных, репутационных и иных потерь. Чтобы ее достигнуть, нужно создать культуру производства, в которой главный критерий – это ценность продукта для бизнеса и вовлеченность в создание этой ценности всех сотрудников.
Концепция Lean пришла из промышленности. Впервые ее внедрил концерн Toyota, чтобы уменьшить потери и приблизить продукт к ожиданиям потребителей. Принципы бережливого производства активно применяли промышленные компании, затем идею подхватили сферы здравоохранения и страхования. Философию успешно масштабировали для управления в ИТ-сфере, и появился термин Lean IТ. Одними из первых ее внедрили Motorola, TransUnion, Fujitsu Services.
На российском рынке представлен большой выбор help desk систем, которые позволяют автоматизировать процессы постпродажного обслуживания. С одной стороны, это хорошо, так как у каждой компании есть возможность подобрать решение для своего бизнеса и под свои задачи. С другой стороны, возникает путаница в том, для чего предназначен тот или иной helpdesk. В попытке протестировать все системы, который выдал поисковик, уходит много времени и сил, а на выходе результат не всегда получается даже удовлетворительным. Что в итоге выбрать и какие есть решения для разных типов поддержки?
Предыстория
Вот уже без малого месяц я копаюсь в исходном коде helpdesk-системы GLPI. И при изучении данного опенсорс-решения обратил внимание на ничтожно малое количество информации для разработчиков. Подавляющее большинство материала связано с настройкой GLPI внутри интерфейса. Немного меньше, но ещё можно встретить информацию по настройке сервера. И всего одна статья (и та на английском) повествует о разработке плагинов для этой чудо-системы.
Из официальных мануалов — пара ресурсов на readthedocs, плюс мануал, сгенерированный из phpdoc'а.
Из сообщества — чат в телеграме и забугорный форум.
Привет, Хабр! Мы – аналитики команды облачного ИТ-сервиса. Наши клиенты – это бизнесмены, которые используют service desk решение. Мы много с ними общаемся и решаем их проблемы, делаем статьи и вебинары о продукте и занимаемся его развитием.
Найти сотрудника, который смог бы выполнять все эти задачи, непросто. Когда количество клиентов начало расти, поняли, что без новых рук не обойтись. Однако поиски затянулись: на рынке нужных кандидатов не оказалось. Решили пригласить стажеров и научить всему сами. И вот – к нам идут четыре студента! Как ввести в строй всех разом? Решение – создать курсы для стажеров за месяц. Задача казалась почти невыполнимой, но мы сделали это! И теперь делимся своим опытом с вами.
