... service desk'a сделать плохой bugtracker? Элементарно, Ватсон!
Отламываем CMDB. До основанья, без "затем". "Нет, он у нас есть, но мы его вам не дадим - он слишком сложный чтобы масштабировать его на все предрпиятие"(Цы). Отламываем web-морду. Не "до основанья", нет - "но мы вам её не дадим", ибо "она не допилена и к заявке нельзя прикладывать файлы"(Цы). Разрешаем прием заявок по e-mail'у. В свободной форме, ага. Тема - в тему заявки. "Классификация? Не, не слышал!"(С) Основным каналом приема делаем - правильно, те-ле-фон. Ну, типа - "если заявка приходит по мылу в свободной форме - все равно придется перезванивать"(Цы). Про то, что заявку НУЖНО оставлять через веб-морду с помощью набора чек-боксов с _автоматической_ первичной классификацией и _автоматическим_ предоставлением "типового решения" из KB мы, разумеется, тоже не слышали. Ах, "у вас не хватает диспетчеров? так вы же сами инициировали создание единого call-центра? Ах, вы в пилот не входите? Ну, да, не входите - но потом ведь войдете! Наверное... А? Запускать? Да со среды. А? Ваши проблемы!"(Ц). Далее запихиваем в SD кучу самостоятельно заполняемых исполнителем полей. В свободной форме, ага. Не, ну требование вести протоколирование действий - еще туда-сюда, но вот просьба указывать РЕАЛЬНО ПОТРАЧЕННОЕ ВРЕМЯ на решение - идиотизм совершенно невдолбических масштабов. А) Исполнитель ну СОВЕРШЕННО не заинтересован предоставлять реальные значения. Никак. А-ну-как по концу месяца выяснится, что он, с-ссабака работал на пять минут меньше положенных 168 часов в неделю? Неее... пусть лучше 200+ часов выйдет... Б) Заказчик НИКАК не может проконтролировать предоставляемые цифры. Не, РТК у нас конечно есть - но в случае реальных проблем в реальной рабочей обстановке провести хронометраж - анрыл чистой воды. Больше того, даже "мотивированный" сотрудник просто физически не сможет сказать, сколько рабочего времени _реально_ потрачено на решение проблемы силами трех отделов в течении двух недель. И да, такого - "в свободной форме, но обязательно" там не то, чтобы много - но есть. Ну и для достижения действительно фейерического тыздеца в систему надо запихнуть, гм... неформализованные и не стандартизованные на текущий момент процессы (Стандарты есть, но по каждой системе - свои, бо аутсорс и разные поставщики услуг со своими политиками.) - например, problem solving и change management. По ITIL'ю, ага. Ну вот типа у вас это вообще никак описано не было, а вот теперь держите Идеального Сферического Коня в Вакууме. Назначайте архитекторов, собирайте комиссии из, минимум, трех человек, "компонуйте изменения-в-релизы" и отчитывайтесь, отчитывайтесь, отчитывайтесь...
Пи-лин. Думал, хуже, чем текущий вариант из емыла с 1цой слабать нельзя в приципе - ан нет, можно и еще как. Надо только 100600 нефти специалистам занести...
Отламываем CMDB. До основанья, без "затем". "Нет, он у нас есть, но мы его вам не дадим - он слишком сложный чтобы масштабировать его на все предрпиятие"(Цы). Отламываем web-морду. Не "до основанья", нет - "но мы вам её не дадим", ибо "она не допилена и к заявке нельзя прикладывать файлы"(Цы). Разрешаем прием заявок по e-mail'у. В свободной форме, ага. Тема - в тему заявки. "Классификация? Не, не слышал!"(С) Основным каналом приема делаем - правильно, те-ле-фон. Ну, типа - "если заявка приходит по мылу в свободной форме - все равно придется перезванивать"(Цы). Про то, что заявку НУЖНО оставлять через веб-морду с помощью набора чек-боксов с _автоматической_ первичной классификацией и _автоматическим_ предоставлением "типового решения" из KB мы, разумеется, тоже не слышали. Ах, "у вас не хватает диспетчеров? так вы же сами инициировали создание единого call-центра? Ах, вы в пилот не входите? Ну, да, не входите - но потом ведь войдете! Наверное... А? Запускать? Да со среды. А? Ваши проблемы!"(Ц). Далее запихиваем в SD кучу самостоятельно заполняемых исполнителем полей. В свободной форме, ага. Не, ну требование вести протоколирование действий - еще туда-сюда, но вот просьба указывать РЕАЛЬНО ПОТРАЧЕННОЕ ВРЕМЯ на решение - идиотизм совершенно невдолбических масштабов. А) Исполнитель ну СОВЕРШЕННО не заинтересован предоставлять реальные значения. Никак. А-ну-как по концу месяца выяснится, что он, с-ссабака работал на пять минут меньше положенных 168 часов в неделю? Неее... пусть лучше 200+ часов выйдет... Б) Заказчик НИКАК не может проконтролировать предоставляемые цифры. Не, РТК у нас конечно есть - но в случае реальных проблем в реальной рабочей обстановке провести хронометраж - анрыл чистой воды. Больше того, даже "мотивированный" сотрудник просто физически не сможет сказать, сколько рабочего времени _реально_ потрачено на решение проблемы силами трех отделов в течении двух недель. И да, такого - "в свободной форме, но обязательно" там не то, чтобы много - но есть. Ну и для достижения действительно фейерического тыздеца в систему надо запихнуть, гм... неформализованные и не стандартизованные на текущий момент процессы (Стандарты есть, но по каждой системе - свои, бо аутсорс и разные поставщики услуг со своими политиками.) - например, problem solving и change management. По ITIL'ю, ага. Ну вот типа у вас это вообще никак описано не было, а вот теперь держите Идеального Сферического Коня в Вакууме. Назначайте архитекторов, собирайте комиссии из, минимум, трех человек, "компонуйте изменения-в-релизы" и отчитывайтесь, отчитывайтесь, отчитывайтесь...
Пи-лин. Думал, хуже, чем текущий вариант из емыла с 1цой слабать нельзя в приципе - ан нет, можно и еще как. Надо только 100600 нефти специалистам занести...
-
-
25.11.2012 в 15:16-
-
26.11.2012 в 08:12-
-
26.11.2012 в 08:49*приподымает волосатое ухо*
-
-
26.11.2012 в 13:43-
-
26.11.2012 в 14:25К тому же я недавно на общий курс ITIL ходил.
Послушал всякое.
-
-
27.11.2012 в 09:22Очень уж... разлаписто-и-развесисто оно у них выходит. Ку-че-ря-во, вот ).
А "Унифицированные SLA" с одной стороны - "хорошо есть, и хорошо весьма", а с другой - на практике они выходят или "слишком уж унифицированными" или нифига не ).
То же согласование регламентных работ по обслуживанию электронной почты на уровне холдинга - тем еще анекдотом было, учитывая тот факт, что "физически" почта на предприятиях вертится а) На sun'овской еще солярке б) на физических серверах с 2003 чангой, в) на виртуальных серверах с 2010ым exchange'ом, г) хостится у сервис-провайдера (Тот же последний чанг as service) - а список регламентных работ с отчетностью по ним - вынь-да-положь. Единый. Стандартизованный ).
И такого получилось... в общем, МНОГО всего получилось. Посмотрим, как работать будем.