Портал №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-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT