Интересующимся вопросами сравнения и выбора ПО – читать вот эту статью от Дмитрия Исайченко. Кратко проанализировано 4 лидирующих софта: HP Service Manager, Axios Assyst, Omninet OmniTracker, BMC Remedy. Ответ на вопрос "что лучше?" автор хитроумно умалчивает, предлагая выбирать самим.
Подход, конечно, верный и политкорректный. Но хочется иногда и врезать правду-матку. Чтобы вендорам неповадно было петь только хвалебные песни, чтобы разработчики и продавцы научились более правильно оценивать творения своей компании.
В прошлом году я участвовал в проекте, где всё от начала до конца было сделано так плохо, как только можно себе представить – начиная как раз от выбора процессного инструмента. И еще тогда возникла мысль написать об этом проекте мини-мемуары, где изменить все имена и события, но оставить канву. Товарищи читатели (я знаю, чтобы вы есть) – было бы интересно читать о таком проекте? Или есть более важные темы для обсуждения? Вендору там пришлось несладко.
понедельник, 18 января 2010 г.
Статья о выборе софта от Димы Исайченко и вопрос к читателям
на 01:22
Ярлыки: article, service desk
Подписаться на:
Комментарии к сообщению (Atom)
27 комментариев:
ps. Единственное замечание по фактам статьи - пока она писалась, HP продлил время поддержки Service Desk 4.5.
Безусловно интересно описание плохого проекта, как передовой опыт. Про такое редко пишут, если не сказать, что не пишут совсем, а то складывается ситуация успешности везде, при этом если капать глубже, то там история про "мертвую лошадь"
см. http://gogolem.ru/obo-vsem-na-svete/mertvaya-loshad-ili-o-strategiyah-reshenia-problem.html
И ещё, у Вас описочка в тексте- "поликорректный", хотя без "Т" смысл получился интересный, т.е "всекорректный", согласно употреблению корня "поли" см. http://www.cultinfo.ru/fulltext/1/001/008/090/727.htm
Что-то я стал делать в записях много опечаток :) Спасибо! Сейчас подправим.
А в этом стиле мне очень нравится история Игоря Ашманова - "Жизнь внутри пузыря", совершенно субъективная оценка событий изнутри.
Да, интересен любой практический опыт и соответствующие выводы, конечно.
Да, и до какого времени продлили поддержку НР?
Спасибо и пишите с чем Вы сталкиваетесь в своих проектах
Анатолий, поддержка HP SD продлена до 2012 года включительно.
Странная метода в статье. Выделили шкалу от 1 до 5, но в одном случае поставили 3.5, что привело к тому, что Remedy круче HP SM аж на полбалла. Поставить Хьюлету за "гибкость" 3 рука не поднялась, но допустить, чтоб HP сравнялась с BMC не хотелось? В итоге трём из 5 продуктов поставили 15 баллов, двум 12 и 13. Т.о. "анализ" не дал никакой информации читателю. Зачем нужна методика сравнения, если в результате её применения ничего ни с чем сравнить не получается? Основной вывод, который следовало сделать в этой статье: "Как вы видите, уважаемый читатель, с помощью данной методики не удалось выяснить решительно ничего, из чего следует, что применять её для сравнения продуктов мы не рекомендуем."
Ого! В комментариях подтянулась тяжелая артиллерия. Жалко, вы не подписались.
Можно ваш отзыв поставить в оригинал поста? Если нужен копирайт, то просто напишите мне.
По сути. Вообще, я в статье Димы нашел несколько недостатков, и вы указали практически на все из них.
Добавлю только:
1) статей сравнения ПО на рынке практически вообще нет, и статья Димы в этом смысле хоть какой-то материал;
2) в 2010 я обязательно напишу цикл статей, в котором собираюсь разрешить вопросы выбора ПО и временно закрыть тему.
Когда будете писать обзор, добавьте, пожалуйста, еще продукт IBM Service Manager. Очень было бы интересно узнать об этом новичке. Спасибо. Читаю Вас с удовольствием.
А как Вы собираетесь сравнивать? Тут даже сравнение в разных проектах не поможет, ведь каждый проект уникален иначе небыл бы проектом. А своими силами тяжело. Такими занимается вообще то forrester research, например http://www.forrester.com/rb/Research/megavendors_in_it_management_software/q/id/43904/t/2
Может кому-то будут интересны для ознакомления статистика и анализ forrester research и gartner :)
Коллеги, отвечаю сразу всем.
Сравнивать будем по методике, которая родилась в результате неоднократного выбора инструмента и для себя, и для заказчиков в проектах. Именно поэтому будет не одна статья, а несколько статей, иначе не получается. Кстати, гартнеровская методика меня абсолютно не устраивает - судя по возмущениям на выходе, на вход подаются очень странные данные, если не сказать хуже.
Увы, но IBM Service Manager в статью с реальным кейсом включить не удастся. Я лично его руками не трогал, а писать буду только о том, что знаю и пробовал лично. Только если найдется профессионал, который внедрял этот софт - тогда с удовольствием включу.
Спасибо, жду с нетерпением. Если хто ндо, пишите :)
крайне скептически всегда относился к подобным статьям и методикам и, пока, судя по этой и подобным статьям, не зря )
почитаем, конечно, что у вас родилось, вдруг чудо :)
Offtopic Матвею: у вас описочка в тексте - "капать глубже", хотя если сначала глубже копать, то потом ведь и капать тоже придется глубже... то есть смысл тот же, просто этап технологического процесса другой. :)
To itsminator: ("А своими силами тяжело.")
...именно потому и интересно. ДИ писал свою статью о том, что видел глазами, делал руками, а перед тем - учился (не инструкцию читал на коробке, а именно учился - не один день и не одну неделю).
При этом не имея целью что-либо кому-либо продать и сохраняя объективность.
Это довольно редкое сочетание в силу особенностей рынка ПО - чтобы и со знанием дела, и независимо в то же время. Поэтому подобных материалов и нет почти.
анониму: ("Т.о. "анализ" не дал никакой информации читателю." и далее):
...а если не просто сложить показатели по разным критериям и объявить эти суммы единственным доступным читателю результатом, но еще и умножить их друг на друга (например), то можно сказать, что смысл и единственный результат статьи - вычисление числа 70, а его большинство читателей и так знало, а потому статья вполне бесполезна.
насколько я знаю (читавшие делились впечатлениями), некоторым из них выяснить удалось существенно больше чем решительно ничего. Хотя ни один из них не пытался что-либо выяснить путем сложения оценок.
правка для внимательных и неленивых:
конечно, не "вычисление числа 70", а "вычисление числа 526500" - поскольку "умножить друг на друга"...
и это, честное слово, не главное.
Важность таких статей имхо ещё в том, что сравниваются более или менее похожие продукты (если автор правильно подходит к вопросу). Потому что инструментов на рынке, особенно в Европе и США немереное количество, с разными уклонами и целевыми ранками/клиентами. Для новичков в ITSM это огромная информация, какие продукты являются именно прямыми конкурентами, а не только продуктами из одной области.
Такие гиганты как Remedy и HP играют в другой лиге, чем, например FrontRange или Service-now и сравнивать их не целесообразно. ИМХО
п.с. jour, спасибо за комментарии
Роман, я бы все приводил исключительно к числу 42.
Кстати, к слову, цитата книги real itsm (о стратегии сервисов) находится как раз на этой странице 8)
jour пишет...
насколько я знаю (читавшие делились впечатлениями), некоторым из них выяснить удалось существенно больше чем решительно ничего.
А поделитесь, пожалуйста, крайне интересно, что выяснили читатели.
Саша, про 42 - мегазачОт :)
"что выяснили читатели":
ну, насколько я их понял, некоторые узнали новое об отдельных продуктах; некоторые нашли полезными списки плюсов и минусов, предшествующие табличкам по каждому продукту; кое-кому показалась полезной сама идея сравнивать эти продукты не только по функционалу, который примерно одинаково хорошо развит...
еще зарегистрированы побочные эффекты - "так вот как работает pink verify"- , но это скорее в силу ограниченной способности многих наших специалистов изучить исходные материалы на английском.
а вообще-то, imho, материал, написанный ДИ, в самом деле может помочь в выборе ПО тем, кто это ПО выбирает или планирует выбирать.
в любом случае, самое интересное в статье - не оценки, конечно, и тем более не их сумма. Дьявол, как напомнил читателям ДИ, в мелочах. Самое интересное - текст между табличками: что именно создает сложности при миграции, да в чем именно состоит хваленая гибкость, да чем обеспечивается лучшая масштабируемость...
то есть если бы зачем-то пришлось выбирать "или-или", я бы таблички с оценками выкинул, а текст оставил. А то кто-нибудь придет и все перемножит... С буквами-то соблазн все свести к одному значению - поменьше, верно?
уже 25 коментов, как минумум повышенный интерес - вот результат той статьи :) хорошо это или плохо?
itsminator пишет...
уже 25 коментов, как минумум повышенный интерес - вот результат той статьи :) хорошо это или плохо?
Предлагаю ввести следующую методику ответа на вопрос "хорошо это или плохо". Введём пяти-бальную шкалу, оценим каждый комментарий по следующим характеристиками:
- "Соответствие теме топика"
- "Бренд - репутация комментатора"
- "Количество букв в комментарии"
- "Соблюдение правил русского языка"
Очевидно, на вопрос методика, конечно, не ответит. Но на пару десятков новых комментов рассчитывать можно.
Отправить комментарий