Pull to refresh
5
0
Кирилл @kfedulov

SaaS, управление проектами, разработка ПО, Okdesk

Send message
Очень жаль, коллеги, что у вас не нашлось времени ответить на вопрос к первой публикации (ниже я его продублирую). Видимо, все силы уходят на такой вот, как эта статья, некачественный PR и продвижение своего собственного решения…

«Не очень похоже на «независимый обзор». Скорее, наоборот. Критерии выбора крайне спорные.

Уточните, почему в списке критериев ничего нет про контроль SLA? Сервисный бизнес в этом не нуждается?
Что делать с учетом разовых работ по прайсу? Сервисный бизнес работает по 2 основным моделям: абонентское обслуживание + разовые работы за рамками «абонентки». Большинство компаний на основании разовых работ премирует сотрудников.
Как быть с выставлением счетов или выписыванием актов/нарядов и т.д.?
Полноценные карточки или паспорта оборудования?
Наличие API?

Что с ценами и быстродействием?

У Hubex, например, «Автоматическое распределение заявок по исполнителям», «Автоматический расчет планового времени выполнения работ / срока реакции по заявке», «доступ к API» начинается с 49 990 рублей/мес и почти всех «конкурентов» это все входит во все тарифы. А впрочем к чему эти детали?»
То есть вам что-то не понравилось и поэтому вы решили поступить также? Хм…

Если вас действительно беспокоит описанное выше, (к сожалению, не знаю как к Вам обращаться — больно «обезличенный» аккаунт) и для того, чтобы дискуссию в комментариях прекратить (дальше либо в личке, либо, пожалуйста, переписывайтесь сам с собой), то:

1. Очень надеюсь, что лично для Вас количество «контента», не означает качество (в ИТ бизнесе, обычно, как раз наоборот, на то он и ИТ бизнес, а не агрегатор новостей), потому что если эти 100 статей такие же, как та, на которую дана ссылка выше, то у меня для Вас плохие новости.

2. Вы подозрительно много комментируете статьи RegionSoft относительно других материалов. Я, честно, очень хочу верить, что это просто интерес к компании и никакого прямого отношения вы к ней не имеете. И если это так, я очень прошу не называть решение коллег, по крайней мере в текущем виде, конкурентом Okdesk. Не потому, что это смешно и не потому, что оно таким не является от слова «совсем», а потому что если это повторять в каждом комментарии (что почему-то делают и коллеги), то доверие к вашей личной «независимой» оценке у людей объективных, анализирующих и понимающих рынок, серьезно обесценивается.

3. Вы совершенно правы по поводу продвижения. Названные Вами коллеги ведут себя, мягко говоря, не очень красиво в рамках «аналитических» статей с рассмотрением «более 20 решений», оперируя бездоказательными фактами и, главное, очень субъективными доводами вида «медленно работает», «перегружен интерфейс» и т.д. Так продвигались в начале нулевых. После указания на некорректность, обещают прислать доказательства в личные сообщения и, конечно, этого не делают. У взрослых такой подход называется манипуляцией и «некачественным PR». Хотя Хабр «стерпит».

4. И тут с Вами согласен. Каждый выбирает себе «партнёра», «поставщика», «решение» по целому ряду факторов. Кто-то по количеству статей или карме, кто-то по подтвержденной результатами экспертизе и компетенциям, отзывам из отрасли, кто-то просто потому что «подход» и поведение в «инфополе» импонирует. Хорошо, что на рынке ПО в нашей стране проблемы этого самого выбора нет, а значит каждый найдет то, что ищет.

Удачи Вам, вне зависимости от выбора, в любых активностях. Время всё расставляет по местам.
Последний комментарий и ссылка на статью уж слишком явная реклама, а обилие скриншотов, скорее намекает на «пользу» контента. Тем не менее она написана на основании нашей старой статьи habr.com/ru/company/okdesk/blog/343976, о чем коллеги забыли написать, поэтому пусть будет
Ваша статья действительно вытекает из нашей, я бы даже намекнул на то, что частично «списана». Поменьше бы прямой рекламы и скриншотов. А так, спасибо за дополнение!
Смотря в чем вы измеряете «шарить в бизнесе» :)
1. Конечно, когда мы ставили запятую между CRM, Help Desk и т.п. мы имели в виду любой класс систем «внутри» которого десятки и даже сотни вариантов почти на любой «вкус» и кошелек.
2 и 3. Это вопрос про TCO и конкретные цифры. Если у вас есть свободные (странное слово для «эффективной» компании) ресурсы (пара мешков) в виде людей, денег и времени на:
— систематизацию и разработку требований;
— перевод требований с языка бизнес потребностей на язык, понятный программистам
— разработку решения на базе требований (нужно учесть, что потребуются люди разных компетенций, например, на разработку Back части, мобильных интерфейсов и т.д.)
— тестирования того, что разработали
— поддержания, администрирования и развития того, что разработали
— и это не считая «инфраструктуры», «лицензирования» и т.д.
То, конечно, можно и самостоятельно разработать, и отдать на аутсорс, и делать, что хочется.
Собственно про этот «велосипед» и речь. С другой стороны: хозяин — барин :)
Не очень похоже на «независимый обзор». Скорее, наоборот. Критерии выбора крайне спорные.

  • Уточните, почему в списке критериев ничего нет про контроль SLA? Сервисный бизнес в этом не нуждается?
  • Что делать с учетом разовых работ по прайсу? Сервисный бизнес работает по 2 основным моделям: абонентское обслуживание + разовые работы за рамками «абонентки». Большинство компаний на основании разовых работ премирует сотрудников.
  • Как быть с выставлением счетов или выписыванием актов/нарядов и т.д.?
  • Полноценные карточки или паспорта оборудования?
  • Наличие API?

Что с ценами и быстродействием?

У Hubex, например, «Автоматическое распределение заявок по исполнителям», «Автоматический расчет планового времени выполнения работ / срока реакции по заявке», «доступ к API» начинается с 49 990 рублей/мес и почти всех «конкурентов» это все входит во все тарифы. А впрочем к чему эти детали?
При всём уважении, с учетом того, что расчет SLA, автораспределение заявок, создание своих типов заявок и даже доступ к API у вас только на тарифе за почти 50 000 руб в мес, до мечты далековато. Точнее мечта уже очень дорогой получается. За такие деньги можно приобретать подписку на Enterprise решения
В этой же ветке ниже мы немного погрузились в обсуждения. Лучше подскажите в чем указанный продукт учитывает а) российскую специфику «сервисных» компаний, а не только ИТ-аутсорсеров б) зачем этим самым сервисным компаниям автоматизация процессов по ITIL со всей её избыточностью?
Сейчас мы уйдем в терминологические споры о том, что такое small бизнес :)
Но по факту это нужно в бОльшей степени ИТ-аутсорсингу, хотя и ему далеко не всегда. Уверенно это заявляю, так как количество ИТ-аутсорсеров, использующих наше решение, измеряется не единицами.
В том, что ITIL в российском сервисном массовом бизнесе слишком избыточен. Если погружаться в детали, то у нас множество специализированных модулей, например, учет объектов обслуживания или «прайс-лист». А также «интеграции» с российским окружением. Я не помню таких возможностей в Manageengine. Зато вижу явную «заточку» под ITIL.
Подскажите, кстати, чем решение для MSP отличается от ITIL ориентированных решений? На сайте в списке модулей — чистая ITSM специфика.
А мы и написали, что Help Desk — это подмножество CRM (а еще к CRM по определению относятся даже колл-центры). Это однако на сутевом уровне, а на функциональном и системном — красиво реализовать функции поддержки и продаж не получается. По крайней мере я не знаю таких примеров :) Потому и получается — за продажи — CRM, а за запросы поддержки — Help Desk.

То, что вы написали про льготы, акции и т.д. — функция чисто CRM-ная и она даже не обязательно связана с поддержкой. То есть никто не мешает рассылать информацию, даже если заявки на обслуживание не регистрируются вовсе.
Конечно, не пропустили. Но этот продукт не учитывает российскую специфику от слова «совсем» и скорее в России популярен также в части автоматизации внутренней поддержки.
Подскажите, что будет с системой и ее развитием/поддержкой, когда Вас в компании не будет?
Позвольте уточнить, какие решения критикуются в данной статье?

С какими критериями и оценками Вы несогласны? Нам, действительно, интересно!
Добрый день!

Спасибо за взвешенный комментарий.

1. Простота и возможность самостоятельной кастомизации включены в критерий «затраты на развитие/сопровождение». Мы действительно считаем легкость кастомизации под собственные нужны важным доводом при выборе решений подобного класса и на практике неоднократно с этим сталкивались. Тем не менее, отмечу, что для компаний рассматриваемого масштаба, уникальность процессов поддержки, скорее надуманна.

2. Да, простота интеграции в отдельный критерий не вынесена осознанно. В изначальном перечне критериев она была. Но проанализировав заказчиков нашего сервиса (еще раз напомню, что он ориентирован на SMB), мы решили это критерий из итогового видения исключить. Объяснение простое — 90% требований к интеграции в таких компаниях сводится к интеграции с почтовым сервером, LDAP и телефонией. А эти интеграционные возможности есть де-факто у решения из каждой категории
В течение почти 2-х лет (с лета 2012 года по весну 2014-го) программа миграции предусматривала лишь необходимость приобретения новой северной лицензии (платформа Naumen Service Desk v.4 — полностью новая) и бесплатный «перенос» всех пользовательских лицензий.

С весны этого года за лицензии ИТ специалистов при миграции необходимо оплатить 20% их стоимости. Необходимость приобретения серверной лицензии осталась.

Вообще говоря, для Enterprise решений такие условия миграции в части лицензий можно считать уникальными. Вопрос стоимости серверной лицензии, как и любой стоимости в принципе — очень дискуссионный. Дешевле нашей серверной лицензии All in One на рынке Enterprise решений класса Service Desk | Service Manager в России попросту не существует.
Такого тренда, по нашему опыту (более 330 проектов внедрения Naumen Service Desk), в действительности нет.

Если рассмотреть компании со стороны очень упрощенной модели зрелости, то в общем случае есть компании:
1) у которых нет потребности в автоматизации (такие мы рассматривать не будем). В нашей терминологии это менее 5 сотрудников службы поддержки
2) которым нужна учетная система для фиксации заявок (такие системы обычно называют Help Desk или Ticket Management системы). Не более 10-15 сотрудников службы поддержки.
3) в которой появляется необходимость повышать исполнительскую дисциплину, есть запросы со стороны бизнеса о качестве поддержки и услуг (появляются страшные слова, вида SLA, KPI и т.д.). Очень часто это, в том числе, распределенные компании. От 15 до 30-ти ИТ специалистов
4) с достаточно сложными процессами и серьезными операционными и управленческими задачами, которые требуют разного подхода (выше 30 ИТ специалистов).

Вне зависимости от классификации о «коробках» так или иначе мы слышим постоянно, но реальность такова, что уже с пункта 3 и выше коробочные решения не способны полностью удовлетворить реальную потребность (опять же, если это не потребность в простейшем учете заявок). Дело и в бОльшей бюрократизированности процессов, и в их уникальности и т.д. и т.п. Для пункта 3) коробки как раз и подойдут для решения общих, обычно, учетных задач на первом этапе. Такие компании очень быстро дозревают до необходимости выходить за рамки автоматизации учета и уже тогда коробочное решение не подходит (поэтому, собственно, и мигрируют). На пункте 3), к слову, в 80% случаев заканчивается желание настраивать самим.

На самом деле любой заказчик хочет получить решение собственных задач (просто задачи сильно различаются по сложности в зависимости, в том числе, от масштабов). В этом смысле «коробка» — это готовое решение задач и автоматизация процессов. Мы такие «коробки» называем проектами «под ключ». Это все равно настройка системы под специфику процессов заказчика (иногда, к слову, и процессы приходится формализовывать и перестраивать), но для него это выглядит как «коробка».
Добрый день!

Ниже krubinshteyn многое прокомментировал. Не могли бы Вы прокомментировать тезис о «странной ценовой политики обновления с 3.x на 4.х»? Что в ней именно странного?

Единственный ресурс, который видел в интернете о «широте» использования этот . Хотя и там данные не очень актуальные.
Симпатично. Но как система ведет или будет вести себя на больших объемах данных? Сколько человек разрабатывало и поддерживает данную систему? Что будет, когда эти люди уйдут?
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity