Comments 29
Довольно много бесплатных аналогов, например я почти везде вижу Help Desk от OTRS.
На мой взгляд, OTRS все хе хорош тогда, когда есть человек, который будет с ним возиться. Преимущество современных SaaS HelpDesk, что из коробки уже доступно многое.
OTRS SaaS стоит дорого, он не бесплатен.
Бесплатно только у себя установить.
Но споры про SaaS или In House — не предмет статьи :)
Мы рассматривали SaaS как риск (рынок не готов и т.д.) — на самом деле этот риск как раз не оправдался.
Бесплатно только у себя установить.
Но споры про SaaS или In House — не предмет статьи :)
Мы рассматривали SaaS как риск (рынок не готов и т.д.) — на самом деле этот риск как раз не оправдался.
Можно сделать еще один вывод: прежде чем писать код, нужно садиться и считать. Количество компаний и сотрудников можно было прикинуть до начала работ, тогда вы бы сразу знали, что надо ориентироваться на другой сегмент. Сам наступал на подобные грабли.
Вы правы, считать всегда нужно до, а не после или во время. Мы как раз посчитали количество «до». А вот «качество» можно было понять только на опыте, к сожалению.
Не совсем, уверен, что показатели по фремиуму можно было получить до разработки. В любом случае, вы получили важный опыт управления. Удачи с новым проектом!
Есть более-менее статистика по freemium в b2c, там говорят про 2-5% платных. К b2b она не подходит (да и у нас получилась 16,6% — сильно больше). Т.е. тут ещё и от правильности freemium-а зависит (у нас был совсем не правильный — в статье тоже об этом написал).
Но, наверное, будь больше опыта и знаний тогда — можно было бы меньше ошибок совершить.
Спасибо за пожелания!
Но, наверное, будь больше опыта и знаний тогда — можно было бы меньше ошибок совершить.
Спасибо за пожелания!
А можете рассказать про процесс разработки? Какая архитектура и почему, какие технологии используете, какие встретились сложности и подводные камни и как с ними боролись, зяли что-то готовое за основу или же все с нуля делали?
В данный момент занимаемся чем-то похожим: взяли за основу редмайн и допиливаем под нужды заказчика.
В данный момент занимаемся чем-то похожим: взяли за основу редмайн и допиливаем под нужды заказчика.
Если речь о Smartnut, то процессы описывали habrahabr.ru/company/itarena/blog/133016/ и habrahabr.ru/company/itarena/blog/134235/
технологии Java + GWT, все писали с нуля.
технологии Java + GWT, все писали с нуля.
Удачи вам, с переосмыслением.
До сих пор используем Naumen ServiceDesk 3.8. Количество сотрудников в системе — 25. Лицензий куплено за всё время — 12. Запросов в системе порядка 5000. В этом году перестали платить за поддержку (не продлили договор).
Ищем альтернативы.
Из рассматриваемых вариантов, ITSM365 отпал практически сразу. Причин несколько:
* цена на сервис ITSM365 — не конкурентная
* не очень хороший опыт в ServiceDesk (сложные вещи не всегда даже понятно как делать, простые — делаются сложно).
* очень странная ценовая политика на обновление 3.x -> 4.x
Передавайте привет коллегам работающим на ServiceDesk. По крайней мере в нашем случае, то, что мы на ваш продукт даже не смотрели внимательно — их заслуга.
До сих пор используем Naumen ServiceDesk 3.8. Количество сотрудников в системе — 25. Лицензий куплено за всё время — 12. Запросов в системе порядка 5000. В этом году перестали платить за поддержку (не продлили договор).
Ищем альтернативы.
Из рассматриваемых вариантов, ITSM365 отпал практически сразу. Причин несколько:
* цена на сервис ITSM365 — не конкурентная
* не очень хороший опыт в ServiceDesk (сложные вещи не всегда даже понятно как делать, простые — делаются сложно).
* очень странная ценовая политика на обновление 3.x -> 4.x
Передавайте привет коллегам работающим на ServiceDesk. По крайней мере в нашем случае, то, что мы на ваш продукт даже не смотрели внимательно — их заслуга.
3.8 старая версия, которая уже 2,5 года не продается. Если за более чем 2,5 года в системе 5000 запросов — то Naumen SD для вас действительно будет излишним. Вы правильно сказали — с платформенных решениях простые вещи делаются сложно, а не простые — не понятно как сходу. Но при этом, они делаются без программирования (а в версии 4.0 — любая модель данных и модель процессов делается «кликами мышки»).
В ITSM365 мы изначально заложили следующую модель — коробочное решение для быстрого старта (доступно на самом простом тарифе) и далее можно, в случае необходимости, кастомизировать под собственные нужды (на тарифах Standard и выше).
На счет не конкурентной цены — спорный вопрос. Т.е. смотря с кем сравнивать. По уровню возможностей кастомизацией — по цене никого близко нет. Если кастомизация не нужна и достаточно только коробки — мы и не конкурируем в этом сегменте. Мы как раз и ушли из более дешевого сегмента, т.к. на нем каши не сваришь. Сейчас, глядя на динамику продаж, считаю что цены вполне приемлемые.
В ITSM365 мы изначально заложили следующую модель — коробочное решение для быстрого старта (доступно на самом простом тарифе) и далее можно, в случае необходимости, кастомизировать под собственные нужды (на тарифах Standard и выше).
На счет не конкурентной цены — спорный вопрос. Т.е. смотря с кем сравнивать. По уровню возможностей кастомизацией — по цене никого близко нет. Если кастомизация не нужна и достаточно только коробки — мы и не конкурируем в этом сегменте. Мы как раз и ушли из более дешевого сегмента, т.к. на нем каши не сваришь. Сейчас, глядя на динамику продаж, считаю что цены вполне приемлемые.
Мы покупали еще 3.6, кажется в 2010 году (можно уточнить). Конечно, 5000 заявок это немного, но мы же вроде о малом бизнесе? Четыре года, ~220 рабочих дней в году — 5 заявок в день.
Что именно вы вкладываете в слова «делаются без программирования»?
При внедрении SD сотрудники Naumen для нас «программировали» скрипт обработчика почты. Сейчас у него уже пятая версия. Там, конечно, всё очень просто (groovy 268 строк, понятные комментарии). Но это таки программирование. Немного огорчало то, что документации по API не было. Нам предлагали курсы, на которых обещали научить. Что и как реализовано в 4.0, увы, нам перестало быть интересно после того как нам озвучили цену на миграцию данных из 3.8.
Сравнение: У нас уже есть сложившаяся практика работы службы поддержки. Появляется продукт-кандидат, например я заметил как-то тут на Хабре анонс, попросил на приглашение, и через какое-то время приглашение пришло.
Дальше процедура примерно такая:
1. есть ли предложение в виде SaaS?
2. дают ли тестовую учетку?
3. если дают — смотрим политику лицензирования, цены, и считаем, во сколько нам будет обходиться в год.
4. если получается ощутимо дешевле, чем мы платили за поддержку ServiceDesk — пробуем
5. регистрируем учетку предприятия, создаем несколько пользователей службы поддержки, создаем несколько клиентов и пытаемся реализовать на практике то, чем мы сейчас пользуемся в SD: Начиная от работы с заявками, продолжая через оперативную картину с точки зрения начальника службы поддержки, и завершая статистической картиной с точки зрения учета по службе в целом.
Хватает ли чего-то «из коробки» или нет — выясняется в пп.5. Но «только коробкой», мы не ограничиваемся. Например, при рассмотрении одного из продуктов нам сказали, что именно вот такого нет, но если заключаем договор — допишем за месяц-полтора без дополнительных денег.
Нет смысла спорить с вами по ценам, но надеюсь есть смысл донести наше видение:
— начиная с $5/мес (180 руб/мес) — обычно есть 95% того, что нам нужно.
— цена $10/месяц (350 руб/мес) — не пугает, но поднимает планку ожидания комфорта при использовании.
У вас получается $15/мес. И вот эти «Именные лицензии», «Конкурентные» — всё усложняют и отталкивают. Как я понимаю, в ITMS365 учетки клиентов (которым оказывают поддержку) тоже лицензируются, аналогично как и в ServiceDesk?
Те варианты, которые мы рассматривали, обычно лицензируют только сотрудников службы поддержки, а клиентов может быть сколько угодно.
Что именно вы вкладываете в слова «делаются без программирования»?
При внедрении SD сотрудники Naumen для нас «программировали» скрипт обработчика почты. Сейчас у него уже пятая версия. Там, конечно, всё очень просто (groovy 268 строк, понятные комментарии). Но это таки программирование. Немного огорчало то, что документации по API не было. Нам предлагали курсы, на которых обещали научить. Что и как реализовано в 4.0, увы, нам перестало быть интересно после того как нам озвучили цену на миграцию данных из 3.8.
Сравнение: У нас уже есть сложившаяся практика работы службы поддержки. Появляется продукт-кандидат, например я заметил как-то тут на Хабре анонс, попросил на приглашение, и через какое-то время приглашение пришло.
Дальше процедура примерно такая:
1. есть ли предложение в виде SaaS?
2. дают ли тестовую учетку?
3. если дают — смотрим политику лицензирования, цены, и считаем, во сколько нам будет обходиться в год.
4. если получается ощутимо дешевле, чем мы платили за поддержку ServiceDesk — пробуем
5. регистрируем учетку предприятия, создаем несколько пользователей службы поддержки, создаем несколько клиентов и пытаемся реализовать на практике то, чем мы сейчас пользуемся в SD: Начиная от работы с заявками, продолжая через оперативную картину с точки зрения начальника службы поддержки, и завершая статистической картиной с точки зрения учета по службе в целом.
Хватает ли чего-то «из коробки» или нет — выясняется в пп.5. Но «только коробкой», мы не ограничиваемся. Например, при рассмотрении одного из продуктов нам сказали, что именно вот такого нет, но если заключаем договор — допишем за месяц-полтора без дополнительных денег.
Нет смысла спорить с вами по ценам, но надеюсь есть смысл донести наше видение:
— начиная с $5/мес (180 руб/мес) — обычно есть 95% того, что нам нужно.
— цена $10/месяц (350 руб/мес) — не пугает, но поднимает планку ожидания комфорта при использовании.
У вас получается $15/мес. И вот эти «Именные лицензии», «Конкурентные» — всё усложняют и отталкивают. Как я понимаю, в ITMS365 учетки клиентов (которым оказывают поддержку) тоже лицензируются, аналогично как и в ServiceDesk?
Те варианты, которые мы рассматривали, обычно лицензируют только сотрудников службы поддержки, а клиентов может быть сколько угодно.
Naumen Service Desk в версии 4 и выше — позволяет вам кликами мышки создавать собственную модель данных со своими атрибутами, связями с между собой, бизнес-процессами, ролями, правами доступа и т.д. В двух слова, конечно, не скажешь. Само-собой, логика обработки писем (если не устраивает стандартная) может кастомизироваться скриптом. Но для скриптования логики каких-то глубоких знаний API не требуется (к тому же, оно описано) + есть много готовых примеров, которые мы предоставляем.
Клиентский доступ не лицензируется вообще. Что в 3.x, что в 4.x. В ITSM 365 тоже — личный кабинет клиента не лицензируется.
Naumen SD — никогда и не был продуктом для SMB (а в 4-й версии мы сфокусировались на более крупном сегменте).
Но право, мы здесь не про Naumen Service Desk (тем более что я по отношению к нему — ответственный за производство, но не за маркетинг/продажи; если хотите — позову профильных коллег пообщаться), а про fail проекта Smartnut.
Клиентский доступ не лицензируется вообще. Что в 3.x, что в 4.x. В ITSM 365 тоже — личный кабинет клиента не лицензируется.
Naumen SD — никогда и не был продуктом для SMB (а в 4-й версии мы сфокусировались на более крупном сегменте).
Но право, мы здесь не про Naumen Service Desk (тем более что я по отношению к нему — ответственный за производство, но не за маркетинг/продажи; если хотите — позову профильных коллег пообщаться), а про fail проекта Smartnut.
Naumen Service Desk в версии 4 и выше — позволяет вам кликами мышки создавать собственную модель данных со своими атрибутами, связями с между собой, бизнес-процессами, ролями, правами доступа и т.дА клиентов устраивает что приходится все самим настраивать? Сейчас наблюдаю такой тренд, что даже крупные заказчики хотят чтоб им дали решение «из коробки» а не конструктор.
Ну мы можем дать и из коробки конечно (готовую преднастройку). Когда есть потребность в кастомизации (у целевых клиентов Naumen SD — всегда есть) — можем и сами сделать проект, можем и помочь клиенту внедрить самостоятельно.
Настраивать систему автоматизации службы поддержки нужно будет по-любому. Вопрос как обычно в том, какие настройки даются из коробки, и насколько легко во всём этом разобраться.
Идеального ответа не может быть. Кто-то считает, что «у нас же типовой случай, неужели нельзя было дать его из коробки», а кто-то наоборот «что за коробочная типовая гадость, у нас есть важные особенности, где всё это настраивать и почему всё так странно?».
Идеального ответа не может быть. Кто-то считает, что «у нас же типовой случай, неужели нельзя было дать его из коробки», а кто-то наоборот «что за коробочная типовая гадость, у нас есть важные особенности, где всё это настраивать и почему всё так странно?».
Такого тренда, по нашему опыту (более 330 проектов внедрения Naumen Service Desk), в действительности нет.
Если рассмотреть компании со стороны очень упрощенной модели зрелости, то в общем случае есть компании:
1) у которых нет потребности в автоматизации (такие мы рассматривать не будем). В нашей терминологии это менее 5 сотрудников службы поддержки
2) которым нужна учетная система для фиксации заявок (такие системы обычно называют Help Desk или Ticket Management системы). Не более 10-15 сотрудников службы поддержки.
3) в которой появляется необходимость повышать исполнительскую дисциплину, есть запросы со стороны бизнеса о качестве поддержки и услуг (появляются страшные слова, вида SLA, KPI и т.д.). Очень часто это, в том числе, распределенные компании. От 15 до 30-ти ИТ специалистов
4) с достаточно сложными процессами и серьезными операционными и управленческими задачами, которые требуют разного подхода (выше 30 ИТ специалистов).
Вне зависимости от классификации о «коробках» так или иначе мы слышим постоянно, но реальность такова, что уже с пункта 3 и выше коробочные решения не способны полностью удовлетворить реальную потребность (опять же, если это не потребность в простейшем учете заявок). Дело и в бОльшей бюрократизированности процессов, и в их уникальности и т.д. и т.п. Для пункта 3) коробки как раз и подойдут для решения общих, обычно, учетных задач на первом этапе. Такие компании очень быстро дозревают до необходимости выходить за рамки автоматизации учета и уже тогда коробочное решение не подходит (поэтому, собственно, и мигрируют). На пункте 3), к слову, в 80% случаев заканчивается желание настраивать самим.
На самом деле любой заказчик хочет получить решение собственных задач (просто задачи сильно различаются по сложности в зависимости, в том числе, от масштабов). В этом смысле «коробка» — это готовое решение задач и автоматизация процессов. Мы такие «коробки» называем проектами «под ключ». Это все равно настройка системы под специфику процессов заказчика (иногда, к слову, и процессы приходится формализовывать и перестраивать), но для него это выглядит как «коробка».
Если рассмотреть компании со стороны очень упрощенной модели зрелости, то в общем случае есть компании:
1) у которых нет потребности в автоматизации (такие мы рассматривать не будем). В нашей терминологии это менее 5 сотрудников службы поддержки
2) которым нужна учетная система для фиксации заявок (такие системы обычно называют Help Desk или Ticket Management системы). Не более 10-15 сотрудников службы поддержки.
3) в которой появляется необходимость повышать исполнительскую дисциплину, есть запросы со стороны бизнеса о качестве поддержки и услуг (появляются страшные слова, вида SLA, KPI и т.д.). Очень часто это, в том числе, распределенные компании. От 15 до 30-ти ИТ специалистов
4) с достаточно сложными процессами и серьезными операционными и управленческими задачами, которые требуют разного подхода (выше 30 ИТ специалистов).
Вне зависимости от классификации о «коробках» так или иначе мы слышим постоянно, но реальность такова, что уже с пункта 3 и выше коробочные решения не способны полностью удовлетворить реальную потребность (опять же, если это не потребность в простейшем учете заявок). Дело и в бОльшей бюрократизированности процессов, и в их уникальности и т.д. и т.п. Для пункта 3) коробки как раз и подойдут для решения общих, обычно, учетных задач на первом этапе. Такие компании очень быстро дозревают до необходимости выходить за рамки автоматизации учета и уже тогда коробочное решение не подходит (поэтому, собственно, и мигрируют). На пункте 3), к слову, в 80% случаев заканчивается желание настраивать самим.
На самом деле любой заказчик хочет получить решение собственных задач (просто задачи сильно различаются по сложности в зависимости, в том числе, от масштабов). В этом смысле «коробка» — это готовое решение задач и автоматизация процессов. Мы такие «коробки» называем проектами «под ключ». Это все равно настройка системы под специфику процессов заказчика (иногда, к слову, и процессы приходится формализовывать и перестраивать), но для него это выглядит как «коробка».
С клиентским доступом очень круто. Да, и правда. Даже интересно, кто и как искал и проверял, когда этот вопрос возник.
Расскажу нашим, думаю порадуются.
Но «именные» и «конкурентные» лицензии, это сложно. Вот совершенно лень думать и считать. Сам факт того, что есть выбор, как бы предлагает выбрать, и всё это напрягает просто на ровном месте. И цена. Цена-цена-цена.
Расскажу нашим, думаю порадуются.
Но «именные» и «конкурентные» лицензии, это сложно. Вот совершенно лень думать и считать. Сам факт того, что есть выбор, как бы предлагает выбрать, и всё это напрягает просто на ровном месте. И цена. Цена-цена-цена.
Добрый день!
Ниже krubinshteyn многое прокомментировал. Не могли бы Вы прокомментировать тезис о «странной ценовой политики обновления с 3.x на 4.х»? Что в ней именно странного?
Ниже krubinshteyn многое прокомментировал. Не могли бы Вы прокомментировать тезис о «странной ценовой политики обновления с 3.x на 4.х»? Что в ней именно странного?
1. в сумме.
2. отдельные деньги за переход на новую версию, отдельные деньги за миграцию данных из старой версии в новую версию
2. отдельные деньги за переход на новую версию, отдельные деньги за миграцию данных из старой версии в новую версию
В течение почти 2-х лет (с лета 2012 года по весну 2014-го) программа миграции предусматривала лишь необходимость приобретения новой северной лицензии (платформа Naumen Service Desk v.4 — полностью новая) и бесплатный «перенос» всех пользовательских лицензий.
С весны этого года за лицензии ИТ специалистов при миграции необходимо оплатить 20% их стоимости. Необходимость приобретения серверной лицензии осталась.
Вообще говоря, для Enterprise решений такие условия миграции в части лицензий можно считать уникальными. Вопрос стоимости серверной лицензии, как и любой стоимости в принципе — очень дискуссионный. Дешевле нашей серверной лицензии All in One на рынке Enterprise решений класса Service Desk | Service Manager в России попросту не существует.
С весны этого года за лицензии ИТ специалистов при миграции необходимо оплатить 20% их стоимости. Необходимость приобретения серверной лицензии осталась.
Вообще говоря, для Enterprise решений такие условия миграции в части лицензий можно считать уникальными. Вопрос стоимости серверной лицензии, как и любой стоимости в принципе — очень дискуссионный. Дешевле нашей серверной лицензии All in One на рынке Enterprise решений класса Service Desk | Service Manager в России попросту не существует.
В том предложении, что пришло нам, была сумма за серверную лицензию, и этот самый перенос лицензий бесплатно. Ок.
На вопрос «а как же заявки, прикреплённые к ним файлы, вот это всё остальное?», нам выдали еще одну сумму в дополнение к первой, которая нам совершенно не понравилась.
Мы в принципе понимаем, что Service Desk — это для гораздо более больших чем мы, мы даже не стали дискуссию начинать.
Обзор рынка SaaS показал, что ваше SaaS-решение по цене выше среднего.
Что такое «Enterprise класс», нам не интересно. У нас 25 учеток в системе, 4-5 заявок в день, рост ни того ни другого не планируется.
Зачем платить за самосвал, даже если он дешевле и лучше, чем все другие самосвалы?
На вопрос «а как же заявки, прикреплённые к ним файлы, вот это всё остальное?», нам выдали еще одну сумму в дополнение к первой, которая нам совершенно не понравилась.
Мы в принципе понимаем, что Service Desk — это для гораздо более больших чем мы, мы даже не стали дискуссию начинать.
Обзор рынка SaaS показал, что ваше SaaS-решение по цене выше среднего.
Что такое «Enterprise класс», нам не интересно. У нас 25 учеток в системе, 4-5 заявок в день, рост ни того ни другого не планируется.
Зачем платить за самосвал, даже если он дешевле и лучше, чем все другие самосвалы?
В итоге решили, что отказываемся от малого бизнеса и смотрим только на средний и верхний сегмент среднего бизнеса. В нашей терминологии это означает, что объект автоматизации (количество сотрудников службы поддержки) от 10 до 30 человек. Так родился ITSM365.А не могли бы поподробнее рассказать что крылось за таким простым на словах переходом к более крупным клиентам? Другая модель бизнес-процессов в приложении или чисто изменение маркетинговой политики и активные продажи?
Для этого сегмента был продукт (ну, почти был — была платформа, на которой быстро можно было сделать продукт) + это сегмент более платежеспособен.
Само приложение «выбросили» — в ITSM365 платформа Naumen SD, которая позволяет глубоко кастомизироваться. В Smartnut такой возможности не было. Ну и такая возможность сегменту, на который переориентировались, нужна.
Само собой, если бы у нас в компании не было платформы Naumen SD, то проект мы просто закрыли бы. Потому как написать такую платформу — это далеко не год работы небольшой команды.
Само приложение «выбросили» — в ITSM365 платформа Naumen SD, которая позволяет глубоко кастомизироваться. В Smartnut такой возможности не было. Ну и такая возможность сегменту, на который переориентировались, нужна.
Само собой, если бы у нас в компании не было платформы Naumen SD, то проект мы просто закрыли бы. Потому как написать такую платформу — это далеко не год работы небольшой команды.
А почему совсем отказались от малого бизнеса? У вас тариф начинается от 5к в месяц при 10 лицензиях. Почему не сделать тариф на 3-их бесплатно или за 1к в месяц без поддержки?
Есть такая мысль — те, кто платежеспособен, заплатит и 5000/мес. Те кто нет — и 1000 не заплатят. По опыту Smartnut-а это так и было.
Sign up to leave a comment.
Fail story проекта SaaS Helpdesk для малого бизнеса