Comments 26
Для успешного управления IT инфраструктурой, нужны люди которые это умеют делать. Инструмент не панацея. Задолбал маркетинговый бред на техническом ресурсе.
Что-то по-моему с вами не согласны немного :) По вашей логике и менеджеры задач при разработке не нужны — главное чтобы был толковый ПМ и маркерная доска. Ну, для гаражного стартапа может быть этого и хватит, да.
Я вот что-то маркетингового бреда в посте не заметил. Нормальное глубокое описание довольно интересного инструмента (к сожалению, только виндового). Таким софтом пользоваться может человек с головой, а вот без подобных программ в большой компании ни одна голова не поможет. Если только разрастить ИТ-отдел до кучи народа и делить работу. Возможно, вам не приходилось админить и инвентаризировать 400 рабочих мест? Осознание пользы подобного сразу приходит.
Полностью соглашусь. А если учитывать, что эта тысяча человек разбросана по офисам всех региональных центров страны — учитывать что, где, у кого, какой «свежести», и кому, что, для чего заказывать (и статус заказа железки на замену (заказана, куплена, отправлена, ждёт установки), например) без подобного п/о, и не важно, на чём оно выполнено — печаль и грусть.
Да, с географически распределённым офисом вообще беда. Помню, пришло письмо «Пищалка в продажах сдохла» из офиса в областном центре. Оказался бесперебойник, которому 7 лет было :) А еще подметил, что сотрудники очень любят тикеты и радостно ими пользуются, потому что могут отслеживать статус решения вопроса и в случае «просрочки» звонить и ругаться. Им приятно, а сисадмину всегда свежая информация. Правда, в тикетах перлов хватало на целый блокнот.
Тут ещё фишка в интеграции, позволяющей отслеживать жизненный цикл рабочего места.
Жаль они решили тупо перечислять имеющиеся фичи в отрыве от реальных сценариев использования, вроде письма счастья от MS или нового начальника ИТ.
Жаль они решили тупо перечислять имеющиеся фичи в отрыве от реальных сценариев использования, вроде письма счастья от MS или нового начальника ИТ.
Хм, я вот прикинул реальные сценарии — это какой величины пост был бы. У вас одни кейсы, у меня другие, а у разработчиков явно третьи. Есть общее описание, а каждый уже примеряет частности на себя. Например, в той конторе на 400 человек, где я работал, смена ИТ-директоров была делом обычным, а они даже не касались нашего админского софта (у нас другой поставщик ПО был, больше акцент на SAM, тикеты самописные). Задача ИТ-шефов была — координировать внедрения биллинга и адского SAP. Писем счастья от MS удалось избежать благодаря неусыпному контролю. А вот на Adobe нарвались, было дело. Так что реальные сценарии, они легко ориентируются на фичи — кому что надо.
Только на реальных сценариях можно понять насколько хорошо продукт решает задачу, а не просто реализует «некий функционал».
Сценарии взял первые пришедшие в голову, а для дебилов из MS вообще нужен скрипт fuck_these_bitches.ps1 с формированием отчёта, так как письма они рассылают рандомно и не могут посмотреть свою же базу покупок в VLSC.
Сценарии взял первые пришедшие в голову, а для дебилов из MS вообще нужен скрипт fuck_these_bitches.ps1 с формированием отчёта, так как письма они рассылают рандомно и не могут посмотреть свою же базу покупок в VLSC.
Ни один сценарий не соберёт всех функциональных возможностей, я прямо уверен в этом. А вот обзор собирает всё. Те же гаджеты не разбирают же по принципу «а вот новый смартфон, рассмотрим его в контексте кейса отправки SMS и MMS» :-) Я вот про SAM знал, про тикеты знал, а вот закупки, например, в таком софте впервые увидел. На моих бывших 400 не помешало бы.
Крупный машиностроительный завод, офис около 500 человек (4 компании, инфраструктура раздельная), провайдер, там около 300 человек. Страховая компания, головной офис 200 человек, + 18 филиалов по стране. Это 10 лет назад. До ухода в чистый IT. Приходилось.
И как обходились, без специализированного софта? Какой штат сисадминов был?
По разному, на заводе 2 человека, в страховой 3, у провайдера около 10, но там своя специфика.
Тикеты, вики, ldap + скрипты, excel, базы данных. Вот и весь софт.
Тикеты, вики, ldap + скрипты, excel, базы данных. Вот и весь софт.
Ааа, понятно. Хороший, достойный набор. Но лень-то раньше родилась, готовый софт удобнее, что говорить. И поддерживать его проще, чем зоопарк из утилит.
Не продали. Такие статьи можно в мегамозге публиковать, там целевая аудитория.
Так я не продаю, я с вами разговариваю и обсуждаю + и — подхода. Мне бы странно было увидеть на Мегамозге пост про софт для сисадмина. Видимо, как-то у вас с оценкой целевой аудитории не сложилось…
А мне, вот, после вашей статьи захотелось Рики-Тики-Тави пересмотреть.
У меня лишь пара вопросов. Зачем скриншоты консольных окон, когда есть веб интерфейс, который наверняка на порядок быстрее работает.
Немного личной боли: Окошко с описанием проблемы видите? Сколько оно место занимает? Менее одной пятой рабочей поверхности. А теперь представьте что вам прислали полотенце текста и два скриншота вставленным в письмо. Что мы там увидим? Правильно! Нифига мы не увидим, пока не по скроллим и не переключимся на какую нибудь вкладку что бы еще и открыть перекинутые из письма во вложения картинки. Самое важное в инциденте (заявке) засунули в прямоугольник размером с пятачок.
Я когда на последней презентации у двух менеджеров продажников hp просил показать кейс прохождения заявки с заданными мною параметрами, знаете что они мне в итоге показали? Как у них в новом интерфейсе красиво менюшки вертятся! Менюшки, Карл!
Про сложность стартового внедрения я умолчу. Много слов про SLA Managment и ITIL на это намекают. У нас MS ServiceManager так и не успел за реалиями роста и потребностями бизнеса, аналог от hp, кхе кхе отпал еще на этапе демонстрации по тем же причинам. Интерфейс перегружен как и всегда.
зыю, из личных потребностей
— ужасное окно заведения заявки. адское. античеловеческое. пожалуйста, пришлите мне видео, где вы сжигаете проектировщика этого интерфейса и менеджера, который это утвердил.
— нет быстрого предпросмотра, что бы заглянуть в заявку и понять что там вообще внутри, если не использовался шаблон или не сработало бизнес-правило автоназначения. экономит уйму времени. обыкновенный попап с первыми 256 символами без форматирования.
— я знаю, что здесь люди технического склада ума, но где русский интерфейс?
— SLA Management, ITIL, бла, бла, бла. Клиенту нужно быстрое решение его проблемы. Вы либо успеваете, либо нет. Вы зад SLA Managementом прикрыли, а клиенту нада было быстрее. Перед законом и по договорам вы чисты, а клиент не доволен. Оп. И нет клиента.
подрожать ms/hp service manager/landesk на мой взгляд… спорное решение. ощутимо бОльшая часть пользователей никогда не заходит на портал и не использует шаблоны. требовать от них красивого заполнения инцидентов как в примерах — глупо.
Немного личной боли: Окошко с описанием проблемы видите? Сколько оно место занимает? Менее одной пятой рабочей поверхности. А теперь представьте что вам прислали полотенце текста и два скриншота вставленным в письмо. Что мы там увидим? Правильно! Нифига мы не увидим, пока не по скроллим и не переключимся на какую нибудь вкладку что бы еще и открыть перекинутые из письма во вложения картинки. Самое важное в инциденте (заявке) засунули в прямоугольник размером с пятачок.
Я когда на последней презентации у двух менеджеров продажников hp просил показать кейс прохождения заявки с заданными мною параметрами, знаете что они мне в итоге показали? Как у них в новом интерфейсе красиво менюшки вертятся! Менюшки, Карл!
Про сложность стартового внедрения я умолчу. Много слов про SLA Managment и ITIL на это намекают. У нас MS ServiceManager так и не успел за реалиями роста и потребностями бизнеса, аналог от hp, кхе кхе отпал еще на этапе демонстрации по тем же причинам. Интерфейс перегружен как и всегда.
зыю, из личных потребностей
— ужасное окно заведения заявки. адское. античеловеческое. пожалуйста, пришлите мне видео, где вы сжигаете проектировщика этого интерфейса и менеджера, который это утвердил.
— нет быстрого предпросмотра, что бы заглянуть в заявку и понять что там вообще внутри, если не использовался шаблон или не сработало бизнес-правило автоназначения. экономит уйму времени. обыкновенный попап с первыми 256 символами без форматирования.
— я знаю, что здесь люди технического склада ума, но где русский интерфейс?
— SLA Management, ITIL, бла, бла, бла. Клиенту нужно быстрое решение его проблемы. Вы либо успеваете, либо нет. Вы зад SLA Managementом прикрыли, а клиенту нада было быстрее. Перед законом и по договорам вы чисты, а клиент не доволен. Оп. И нет клиента.
подрожать ms/hp service manager/landesk на мой взгляд… спорное решение. ощутимо бОльшая часть пользователей никогда не заходит на портал и не использует шаблоны. требовать от них красивого заполнения инцидентов как в примерах — глупо.
А идеальное решение вообще существует?
В Jira Service Desk прекрасный интерфейс, но это просто база заявок без какой-либо интеграции с SAM и CM.
В Jira Service Desk прекрасный интерфейс, но это просто база заявок без какой-либо интеграции с SAM и CM.
Ну как вариант ManageEngine ServiceDesk Plus. SAM, CM, AM и прочие прелести взрослых инфраструктур конечно за деньги, как впрочем и у всех. Зато есть бесплатная версия по ServiceDesk взрослой коммерческой системы без ограничения на количество авторов заявок, интеграцией и авторизацией по AD.
Не идеально, но куда ближе чем остальные, по-моему.
Не идеально, но куда ближе чем остальные, по-моему.
Что значит идеальное?
На текущий момент от SD ожидают собственно системы заведения тикетов, БДКЕ, БДПО, возможности кастомизации интерфейсов и некоторое количество интеграционных интерфейсов (CLI, API, WebServices) и адаптеров.
Всё остальное (дискаверинг, мониторинг, контроль конфигураций, системы оповещения) включая зонтичные системы интегрируются между собой под нужды конкретного заказчика.
На текущий момент от SD ожидают собственно системы заведения тикетов, БДКЕ, БДПО, возможности кастомизации интерфейсов и некоторое количество интеграционных интерфейсов (CLI, API, WebServices) и адаптеров.
Всё остальное (дискаверинг, мониторинг, контроль конфигураций, системы оповещения) включая зонтичные системы интегрируются между собой под нужды конкретного заказчика.
похоже проектировщик интерфейса прочитал мой комментарий, и он с ним не согласен :)
Спасибо за комментарий ) видео сжигания снять не могу — из гуманистических соображений. но давайте попробую ответить по существу.
— в наличии редакторы как процессов, так и пользовательских форм, полей, шаблонов действий и т.п. — в той же заявке нет проблем сделать её в несколько страниц (табов), с полем description хоть на все окно.
— просмотр в наличии — в приведенных скриншотах он, к сожалению, не показан. Выглядит например вот так
— в наличии редакторы как процессов, так и пользовательских форм, полей, шаблонов действий и т.п. — в той же заявке нет проблем сделать её в несколько страниц (табов), с полем description хоть на все окно.
— просмотр в наличии — в приведенных скриншотах он, к сожалению, не показан. Выглядит например вот так
Sign up to leave a comment.
Alloy Navigator: второй пилот для ИТ-инфраструктуры