Pull to refresh

Comments 13

Слишком много маркетинга. Непонятные шкалы с оценками в картинках. Кто оценивал, по каким критериям?
Нет, я вас конечно понимаю, денег хочется всем, но всё же — вы на хабре.
Последнее время вообще возмущен корпоративными блогами (не всеми, конечно, Яндекс и Mail.ru молодцы). Вы действительно считаете что на данном ресурсе подходящая для таких статей аудитория?
1) Если по существу говорить о критериях оценки решений, то следует учесть что ITSM это хорошо, но все-таки в компаниях есть бизнес процессы, которые устоялись и подгонять их под практики (которые являются рекомендациями) не стоит. Так вот, одним из критериев это дорабатываемость под существующие бизнес процессы предприятия. Причем оценивают возможность доработок не силами подрядчика, а собственными силами.
2) У многих компаний возникает потребность в интеграции систем. Даже если потребности нет при внедрении продукта, она может возникнуть на стадии эксплуатации. Даже в случае с Service Desk возникает потребность в интеграции, к примеру, с IP телефонией. Второй критерий — возможности интеграции.

Для меня, как системного архитектора, это два самых важных критерия при выборе любой системы.
К сожалению, чаще всего решения по выбору ITSM (и не только) идут по принципу «у кого больше откат».
А потом приходится платить, платить и еще раз платить за внедрение, сопровождение, обновление, разработку новых фишек-фенечек либо «продавцам», либо внешним разработчикам, либо искать разработчиков-допильщиков себе в штат и платить уже им.
По личным ощущениям, хорошо если в одном случае из десяти проводится вдумчивый анализ и выбор подходящей системы.
И такая ситуация, кстати, не только в гос.организациях, но и вполне коммерческих, доросших до необходимости такой системы.
Добрый день!

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

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

2. Да, простота интеграции в отдельный критерий не вынесена осознанно. В изначальном перечне критериев она была. Но проанализировав заказчиков нашего сервиса (еще раз напомню, что он ориентирован на SMB), мы решили это критерий из итогового видения исключить. Объяснение простое — 90% требований к интеграции в таких компаниях сводится к интеграции с почтовым сервером, LDAP и телефонией. А эти интеграционные возможности есть де-факто у решения из каждой категории
Успешно написал и поддерживал самописный SD, все время его надобности. Сейчас пишу новый под новые потребности (заказчик тот же). Статья — просто реклама, и необоснованная критика других решений.
покажите свой сабж (с)
Позвольте уточнить, какие решения критикуются в данной статье?

С какими критериями и оценками Вы несогласны? Нам, действительно, интересно!
Та, чесно говоря, статья это гроб для мозгов… Мне мало что понятно из нее…
С критериями собственной разработки не согласен.

Экономия затрат на разработку: 1 Мне тяжело судить, но выходя из того, что я не только SD пишу, а еще и другие работы выполняю, то я бы поставил 3
Экономия затрат на развитие/сопровождение: 2 Возможно на сопровождении особо не «разженешся», т.к. продавцы ПО включают ее в цену, по-этому не буду оспаривать.
Скорость внедрения: 1 Со скоростью внедрения не буду спорить, потому что, ПО можно купить и уже внедрять, а если писать самому, то это явно дольше. Но возникшую проблему решаю в пределах нескольких минут, в сравнении с длинной возней с саппортом разработчиков ПО, которые вообще могут не отвечать на запрос.
Возможность масштабирования: 1 Я бы поставил 3, т.к. я, например, знаю собственную программу «от А до Я» и могу ее масштабировать вдоль и поперек.
Уверенность в результате: 1 Я бы поставил 3. Исключением будет только, если ее будут писать студенты или школьники…
Подскажите, что будет с системой и ее развитием/поддержкой, когда Вас в компании не будет?
Система узкоспециализирована и проста (столько функционала, как в приобретенном ПО точно никому не нужно, т.к. одни одно используют, другие — другое) — любой специалист быстро сможет разобраться в коде и продолжить разработку.
Тоже искал готовый (платный или опенсурс) хелпдеск для компании на 300+ десктопов 4-5 лет назад с возможностью интеграции с существующей инфраструктурой и настройкой под себя.

Не нашел, в итоге писал сам в факультативном режиме, хотя я скорее админ и не программист ни разу :)
Ничего, работает, уже более 20 тысяч тикетов в ней было открыто, причем не только в ИТ отдел, но и в другие тоже.
Функционал дорабатывался в процессе.

Так что все эти ваши ITSM и ITIL это хорошо (утомили соискатели про них в резюме писать, чесслово), но как доходит до дела — всё упирается в суровую реальность.
В целом, понятная и простая классификация ITSM решений, которые, именно, что направлены на автоматизацию внутренних ИТ процессов.
Для сервисной поддержки среднему и малому бизнеса такие решения избыточны. Лучше попробовать что-то специализированное, например, простую Help Desk систему Okdesk.
В ней есть и CRM модуль, и возможность вести работу с объектами обслуживания, с оборудованием, договорами и т.д. Всё, что нужно для поддержки юридических лиц
Sign up to leave a comment.