Портал №1 по управлению цифровыми
и информационными технологиями

Вопрос из зала: какой инструмент выбрать для сервис-деска?

Опубликовано 6 июля 2012
Рубрики: Service Desk, Инструменты
Комментарии

Денис задает нашему сообществу довольно популярный вопрос: какое приложение для нужд сервис-деска выбрать?

Здравствуйте, я являюсь одним из соучредителей небольшой компании которая занимается оказанием услуг населению в сфере ИТ.

Сейчас наша компания стоит перед выбор программного обеспечения для управления инцидентами (service desk).

Приоритетные задачи:

1. учёт рабочего времени сотрудников.

2. складской учёт

3. оценка работы со стороны клиента.

4. учёт выручки мастеров.

5. Трудозатраты.

и всё в этом духе :)

Спасибо за внимание.

Также по теме:

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

Комментариев: 28

  • Олег Скрынник

    Денис, смотрели на SmartNut? Не очень знаю про текущую реализованную функциональность, но это приложение «заточено» под небольших провайдеров ИТ-услуг.

    Оно очень динамично развивается и совсем не дорого стоит.

  • Дмитрий Исайченко

    Из небольшого-недорого смотрите прежде всего на OTRS и ManageEngine ServiceDesk Plus. Плюсы: доступность, нет перегрузки ненужным функционалом. Минусы: гибкость (шаг в сторону — программирование под вэб), нехватка развитых функций управления.

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

    Неплохая статья по выбору ITSM ПО есть здесь: www.cleverics.ru/ru/subje...on-itsm-software.

  • Pavel Solopov

    складской учёт и учёт выручки мастеров, не очень стандартные задачи для решений класса Service Desk.

    Посмотрите вот тут list.ly/list/N8-russian-i...s?feature=mylist список софта, который в том или ином виде существует в России.

    На рейтинг только не обращайте особого внимания, он там живёт своей жизнью. 🙂

  • Vladimir Kapustin

    Если есть чёткое понимание хотелок, то нет ничего лучше самописной системы.

    • Дмитрий Исайченко

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

      1. Традиционные сложности in-house систем (зависимость от разработчиков, слабый уровень документирования и так далее, все знают).

      2. Много раз сталкивался с тем, что первый блок «хотелок» был понятен, под них и писали. Со временем картина мира менялась, и постоянно вставал вопрос об архитектуре системы. Целостное представление, достаточное для реализации более-менее приличной ITSM-системы, редкость.

      Ну и по стоимости — это не экономия (и для дорогих продуктов, и для дешёвых).

      • Vladimir Kapustin

        Готов спорить 🙂

        1. Когда разработчики свои, то зависимость от них не так и плоха. А за документированием — да. Надо следить.

        2. Так это же прекрасно! Как раз в системе, которая писалась своими специалистами под себя отлично реализуется PDCA или CSI. Все рядом, все знают как и что писалось/внедрялось/какие_сложности... Улучшать можно бесконечно.

        Ну и по стоимости — у меня для дешёвых вышла экономия.

        • Дмитрий Исайченко

          Так я ж и говорю: «Для кого-то это может быть правдой». Но точно не для всех. Тут целый ряд нюансов.

          Например «Когда разработчики свои, то зависимость от них не так и плоха». Во-первых «Пока разработчики свои...». Во-вторых, вс

          • Vladimir Kapustin

            В таком случае можно и на крах внешнего разработчика заложиться.

        • Дмитрий Исайченко

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

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

          Ещё раз, я никого не отговариваю — это один из путей. Но он не так светел и прям, как может показаться.

          • Vladimir Kapustin

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

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

            По сути согласен. Нужно аккуратнее **** «нет ничего лучше» 🙂

      • Олег Скрынник

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

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

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

        Собственно, говорю по опыту, мы так в Инкоме и делали — сначала на простой самописной системе работали, потом перешли на хорошее вендорское решение.

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

        • Дмитрий Исайченко

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

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

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

          Жизнь — разнообразнее любых универсальных рецептов 🙂

          • Олег Скрынник

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

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

            «Тут главное иметь мозг» — точно, он нужен 🙂

  • ZW

    > Cейчас наша компания стоит перед выбор программного обеспечения для управления инцидентами (service desk).

    Приоритетные задачи:

    1. учёт рабочего времени сотрудников.

    2. складской учёт

    3. оценка работы со стороны клиента.

    4. учёт выручки мастеров.

    5. Трудозатраты.

    --------------

    Я может что-то не понял, но каким образом 1,2,4,5 имеет отношение к сервисдеску?

    • Дмитрий Исайченко

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

      Кроме того, сам термин «Сервис деск» с точки зрения автоматизации не имеет чётких границ. Возьмите хотя бы отменённые в прошлом году магические квадраты Гартнера по решениям класса integrated service desk и удивитесь наличию в Сервис деск функций управления конфигурациями и изменениями, например. Тогда и трудозатраты со складским учётом уже не будут касаться чем-то удивительно далёким 😉

      • ZW

        1. учёт рабочего времени сотрудников.

        Зарплату тоже оно считать будет?

        2. складской учёт

        Интеграция с финасовым документооборотом для согласования оплаты счётов, выдачи товара и тп?

        4. учёт выручки мастеров

        см. вопрос про зарплату.

        5. Трудозатраты

        Кто будет определять трудозатраты?

        • Дмитрий Исайченко

          Это хорошие вопросы, но не ко мне 🙂

          При этом думаю вопрос 5 на этапе первичного анализа рынка ПО задавать преждевременно. На этапе постановки задачи на реализацию — обязательно.

          • ZW

            Так и возникает вопрос, почему в списке требований к ПО сервисдеска есть три вопроса к ПО финансового документооборота?

            • Олег Скрынник

              Потому что компания маленькая. См. условия задачи 🙂

              • ZW

                Компании стоит подумать про excel?

                А для деска взять ZOHO MenageEngine ServiceDeskPlus.

        • Олег Скрынник

          «Зарплату тоже оно считать будет?» — в небольшой компании зарплату запросто считает Excel. А вот рабочее время лучше планировать там же, где заявки.

          «4. учёт выручки мастеров» — вот это я тоже не очень понял. Возможно, хочется видеть поле «Сколько привёз денег» в конкретной заявке.

          Вообще мне кажется, что вопрос про довольно простую систему и небольшую компанию, а мы тут привыкли оперировать масштабами «сотни айтишников».

          В небольших же ИТ-компаниях всё несколько проще, на мой взгляд.

          • ZW

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

            • Олег Скрынник

              Согласен.

              Но автор вопроса и не говорил про срочность или первую необходимость.

              С другой стороны — мы, к примеру, до системы собственной автоматизации доросли очень быстро, а именно через 7 месяцев работы (www.cleverics.ru/ru/about...ker-at-cleverics). Хотя зарплату тогда считали в Excel.

              • ZW

                Но для компании, которая сама занимается ITSM — сервисдеск вещь первой необходимости:)

            • Vladimir Kapustin

              И уровень обслуживания клиентов вещь не первой необходимости?

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

            • Дмитрий Исайченко

              «если компания настолько маленькая, что считает зарплату в Excel, то ПО сервисдеска для неё вещь не первой необходимости»

              Странное рассуждение, как будто расчёт зарплаты — главная функция, и пока она не автоматизирована, странно заниматься чем-то ещё 🙂

              Расчёт зарплаты — внутренняя функция компании, она не приносит ни клиентов, ни денег. В то время как система SD в данном случае должна поддерживать основные бизнес-процессы — то, чем компания живёт и зарабатывает. Так во что в первую очередь нужно инвестировать?

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

  • Волков Николай

    Смотрите в сторону упоминавшейся здесь OTRS: есть CMDB — заведёте там склад, есть учёт времени на заявки — посчитаете трудозатраты, есть опросы конечных пользователей — будет и оценка работы. Это всё из коробки и бесплатно, на любой платформе заработает. otrs.org

    • Дмитрий Исайченко

      «есть учёт времени на заявки — посчитаете трудозатраты»

      Вот это конечно заблуждение. К сожалению, весьма распространённое.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM
Авторы и редакторы портала — консультанты и тренеры компании Cleverics.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.