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

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

Опубликовано 6 июля 2012
Рубрики: Service Desk, Технологии, автоматизация, ПО для ITSM
Комментарии

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

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

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

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

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

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

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

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

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

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

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

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

«VAP: Управление поддержкой ИТ-услуг»
Строим эффективную ИТ-поддержку, оптимизируем существующую

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

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

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

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

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

    Из небольшого-недорого смотрите прежде всего на OTRS и ManageEngine ServiceDesk Plus. Плюсы: доступность, нет перегрузки ненужным функционалом. Минусы: гибкость (шаг в сторону – программирование под вэб), нехватка развитых функций управления.
    Если, посмотрев на эту пару, вы поймёте, что это Вам не подходит (и сможете сформулировать почему), возвращайтесь, мы подскажем следующий шаг 🙂
    Неплохая статья по выбору ITSM ПО есть здесь: http://www.cleverics.ru/ru/subject-field/articles/349-selection-itsm-software.

  • Pavel Solopov

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

    Посмотрите вот тут http://list.ly/list/N8-russian-itil-itsm-tools?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 месяцев работы (http://www.cleverics.ru/ru/about/news/125-omnitracker-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.
Использование материалов данного сайта допускается исключительно с разрешения правообладателя.
Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.