Считаю своим долгом сообщить, что скорее всего эту дискуссию продолжит новый руководитель направления "ИнфраМенеджер". Я меняю как место работы, так и сферу приложения своих сил. Это не связано никоим образом с ИМ. Могу только сказать, что лучшего положения с продуктом за всю его историю не было и тенденция к оптимизации налицо!
[/quote]
Добрый вечер всем участникам!
Меня зовут Андрей Рассамакин, я являюсь новым руководителем направления "ИнфраМенеджер" в компании Софтинтегро.
Дмитрий Дашкевич
Цитата
1. Принимаем к исправлению.
2. Не уверен. Во всяком случае есть пока более приоритетные задачи.
3. Вставим описания переменных в HELP.
4. Отредактируйте шаблон по своему усмотрению.
5. Отключите ненужные оповещения. А что касается диспетчера - не во всех ИТ-службах есть выделенный на должность диспетчера сотрудник.
6. Мы вносим Ваше замечание для реализации в будущем.
7. Да, а какие предложения?
8. А зачем он???? Ведь есть же класс Запрос на услуги??? Зачем расширять количество вариантов?
9. Извините, мы запутались smile.gif Давайте попробуем сформулировать почётче.
10. Да. До этого руки ещё не дошли. Будем исправлять.
11. А как же включаемый в KPI параметр "Процент заявок, закрытых на первой линии"?
12. Это сделано для того, чтобы не создавать потом рабочие места, а растащить их по комнатам вместе с пользователями мышкой.
[/quote]
Отвечаю на оставшиеся вопросы.
12. (Насчет кнопки Сохранить). Учтем данное замечание.
13. Инсталляция ПО может быть указана как источник проблемы. Для этого проблему нужно соответствующим образом классифицировать и указать на конкретную инсталляцию.
14. Согласны, учтем.
15. Базу знаний в любом случае будем переделывать, в том числе учтем и это замечание.
16. Если речь об открытии заявки, то шаблон общий с Web.
17. Какой поиск хотелось бы? По инв. №, по IP, по имени…?
18. Проверим.
19. Проверим.
20. Согласны, учтем.
21. С цветовой гаммой не просто. Слишком много различных состояний. Не запутаться бы.
22. Не вижу положительного момента в таком пересмотре. Какие трудности имеются в виду?
23. Согласны, учтем.
11. Так и не понял что с обсуждением этого вопроса кстати не только меня заинтересовал этот момент ))
13. Мы о разных вещах... я имел ввиду что при выборе единицы оборудования есть техническая возможность добавить инсталляцию ПО на выбранном объекте, чтобы потом сослаться на эту инсталляцию в инциденте. Так вот я добавляю инсталляцию и она не сохраняется для последующего выбора в качестве источника проблемы.
17. По названию и по инвентарному номеру. Неплохо так же добавить возможность выбора из всего оборудования в комнате и не тырканьем по рабочим местам.
21. Не обязательно выделять именно цветом, но выделять надо. Если у меня закрывается проблема к которой прикручено несколько десятков обращений, то искать все что надо закрыть крайне неудобно.
22. Проблема весьма проста. Сейчас каталог имеет древовидную структуру, которая предполагает, что, например операция (услуга) настройка ПО или консультация относиться в контексте каталога к конкретному сервису, с одной стороны это верно, но с другой при попытке проанализировать какой процент поступивших запросов привел к потребности изменения настроек ПО задача не тривиальная. Если взять в качестве примера ваш каталог услуг в применении к клиентам то он весьма прост, но, тем неменее, если обратите внимание, перечень услуг в каждой из груп похож если не полностью повторяет соседний, представте что твориться в каталоге немаленькой компании в сети которой эксплуатируются несколько десятков различных приложений и их число растет? Вот тут и выползают грабли Зайдя на сайт поддержки в раздел "Запрос на услуги" простой пользователь падает в обморок.
MacMaster Предлагаю чтбы не запутаться отвечать на перечень вопросов редактированием поста со списком ответов добавляя их по мере необходимости, я в свою очередь буду править список вопросов аналогичным образом. Вопросы других участников я буду добавлять в общий список...
11. Так и не понял что с обсуждением этого вопроса кстати не только меня заинтересовал этот момент ))
13. Мы о разных вещах... я имел ввиду что при выборе единицы оборудования есть техническая возможность добавить инсталляцию ПО на выбранном объекте, чтобы потом сослаться на эту инсталляцию в инциденте. Так вот я добавляю инсталляцию и она не сохраняется для последующего выбора в качестве источника проблемы.
17. По названию и по инвентарному номеру. Неплохо так же добавить возможность выбора из всего оборудования в комнате и не тырканьем по рабочим местам.
21. Не обязательно выделять именно цветом, но выделять надо. Если у меня закрывается проблема к которой прикручено несколько десятков обращений, то искать все что надо закрыть крайне неудобно.
22. Проблема весьма проста. Сейчас каталог имеет древовидную структуру, которая предполагает, что, например операция (услуга) настройка ПО или консультация относиться в контексте каталога к конкретному сервису, с одной стороны это верно, но с другой при попытке проанализировать какой процент поступивших запросов привел к потребности изменения настроек ПО задача не тривиальная. Если взять в качестве примера ваш каталог услуг в применении к клиентам то он весьма прост, но, тем неменее, если обратите внимание, перечень услуг в каждой из груп похож если не полностью повторяет соседний, представте что твориться в каталоге немаленькой компании в сети которой эксплуатируются несколько десятков различных приложений и их число растет? Вот тут и выползают грабли Зайдя на сайт поддержки в раздел "Запрос на услуги" простой пользователь падает в обморок.
[/quote]
Прошу прощения за задержку с ответом - не всегда имею возможность оперативно отвечать на форуме, так как не всегда нахожусь на рабочем месте.
Отвечаю на вопросы:
11. Вопроса здесь я не вижу. Есть несколько утверждений. Полный перечень сформулировать не берусь, но некоторые можно попробовать прояснить.
а) Можно подумать, что без трехуровневой иерархии объектов, описанной выше, обязательно присутствие на 1-ой линии высококвалифицированного специалиста. Нам представляется, что начальную классификацию обращений в состоянии выполнить даже не диспетчер, а конечный пользователь, если сформулировать эту классификацию в его терминах, в терминах сервисов, которые он потребляет. Вообще не вполне понятно назначение объектов категории «обращение».
б) Диспетчер должен быть в состоянии не только рассмотреть заявку, но и найти решение, если оно уже известно и ранее использовалось, или ответ на вопрос, если он уже ранее задавался или заранее предполагалось, что такие вопросы будут, и ответы на них приготовлены. Отсюда упоминание о проценте заявок, закрываемых на первой линии.
в) Привязка инцидентов к проблемам именно так и реализована в системе: Проблема регистрируется ИТ – специалистом, с ней связывается один или несколько инцидентов, и инциденты, привязанные к ней закрываются при закрытии проблемы автоматически.
13. То есть речь идет о том, чтобы во время регистрации заявки изменить конфигурацию оборудования, используемого пользователем? Если это так, то, строго говоря, это выглядит как передача диспетчеру функций по управлению конфигурацией. В небольших командах, наверное, встречаются такие совмещения ролей, но в общем случае можно усмотреть тут дефект процесса управления конфигурацией.
17. ок, подумаем на эту тему
21. Ну, в описанной ситуации как раз искать ничего не нужно: все будет закрыто автоматически. И в любой момент, если вы откроете проблему, то список «прикрученных» инцидентов будет виден на соответствующей закладке.
22. Нам не верится, что, как бы ни была велика компания, простой пользователь этой компании использует больше 10-15 сервисов и что услуг по каждому сервису больше 10. Если это так, то тут какая-то "неправильность" в каталоге или в SLA. Скорее всего, общее число услуг, которыми пользуется простой пользователь, вряд ли превосходит 50 и разбито это число еще на сервисы. Попытка выделить какие-то родовые услуги (настройка ПО совершенно различного вида), присущие нескольким сервисам, возможно и сократит общее число услуг в каталоге, но запутает ситуацию вне сомнения. Проблему со статистикой, если она есть, нужно решать, не вовлекая сюда конечного пользователя. Например, через статистку заданий или через дополнительные параметры услуг.
24. Для регистрации и обработки запросов вида MAC (Move, Add, Change) требуется особое внимание и мы планируем его уделить. Нужно ли делать какие-то специальные составные запросы и тем самым нагружать конечного пользователя – не очевидно.
25. Внесем в список пожеланий и возможных доработок, но пока ничего обещать не могу (если выйдет то не в самых ближайших релизах)
11. Вопроса здесь я не вижу. Есть несколько утверждений. Полный перечень сформулировать не берусь, но некоторые можно попробовать прояснить.
а) Можно подумать, что без трехуровневой иерархии объектов, описанной выше, обязательно присутствие на 1-ой линии высококвалифицированного специалиста. Нам представляется, что начальную классификацию обращений в состоянии выполнить даже не диспетчер, а конечный пользователь, если сформулировать эту классификацию в его терминах, в терминах сервисов, которые он потребляет. Вообще не вполне понятно назначение объектов категории «обращение».
[/quote]
Основная цель классификации обращений - сбор статистики для последующего анализа тенденций и управления процессом. Адекватную классификацию порой не в состоянии выполнить даже ИТ специалист не говоря уж о диспетчере. Мне например как руководителю с целью оптимизации услуг интересно видеть исходные формулировки в обращении пользователя и последующую классификацию этого обращения при привязке к инциденту (если таковая требуется). Назначение объектов типа "обращение" - автоматическая регистрация ВСЕГО что поступает на линию SD. Но не все из поступившего подлежит дальнейшей обработке. Грубо говоря если мне на SD пришло письмо с просьбой выкопать яму я его зарегистрировал (автоматически), но в дельнейшую работу не пустил ибо это за пределами моих компетенций.
Вот еще одна очень распространенная ситуация корректная реализация которой возможна только в трехуровневой модели.
Звонит мне мой руководитель и говорит, что у некоего вождя Васи срочно что-то надо сделать, я корректно отправляю его передать Васе куда надо обратиться. Но первый факт обращения уже состоялся! Как его фиксировать? Далее после внушения помощница великого Васи звонит в SD по поручению Васи после того как ему рассказали куда идти (второе обращение)... Через некоторое время, начальница секретариата звонит на SD с вопросом кагдила?(третье обращение). Все эти обращения - трудозатраты персонала SD на их обработку и параметр для аналитики мне как руководителю они нужны для анализа и отчета.
Цитата
б) Диспетчер должен быть в состоянии не только рассмотреть заявку, но и найти решение, если оно уже известно и ранее использовалось, или ответ на вопрос, если он уже ранее задавался или заранее предполагалось, что такие вопросы будут, и ответы на них приготовлены. Отсюда упоминание о проценте заявок, закрываемых на первой линии.
[/quote]
Да именно и еще проконтролировать ход исполнения и своевременность закрытия. И много чего еще. Должен и может это несколько разные понятия. Есть еще такое понятие как уровнь зрелости и невозможно с 0 подняться сразу до 3-го надо пройти ряд промежуточных этапов. Для этого требуется гибкость системы в части изменения структуры сервисов (услуг)
Цитата
в) Привязка инцидентов к проблемам именно так и реализована в системе: Проблема регистрируется ИТ – специалистом, с ней связывается один или несколько инцидентов, и инциденты, привязанные к ней закрываются при закрытии проблемы автоматически.
[/quote]
А вот автоматически ничего закрываться недолжно! Где гарантия что классификация произведена верно и инцидент зарегистрированный ранее был вызван ТОЛЬКО проблемой к которой он был привязан ранее???? Где механизм контроля? На мой взгляд как минимум должна быть процедура запроса подтверждения необходимости закрыть связанные инциденты!
Цитата
13. То есть речь идет о том, чтобы во время регистрации заявки изменить конфигурацию оборудования, используемого пользователем? Если это так, то, строго говоря, это выглядит как передача диспетчеру функций по управлению конфигурацией. В небольших командах, наверное, встречаются такие совмещения ролей, но в общем случае можно усмотреть тут дефект процесса управления конфигурацией.
[/quote]
Я согласен, что выглядит это несколько неправильно, но для определенных стадий зрелости лучше дать возможность зафиксировать факт изменения состава ПО, чем оставить этот момент без внимания (отсутсвие зафиксированного факта инсталляции ПО может быть связан с ошибками при инвентаризации). Если же придерживаться рекомендаций ITIL, то просто проверьте факт возможности и заблокируйте ее там где такой возможности быть не должно.
17. ок, подумаем на эту тему
Цитата
21. Ну, в описанной ситуации как раз искать ничего не нужно: все будет закрыто автоматически. И в любой момент, если вы откроете проблему, то список «прикрученных» инцидентов будет виден на соответствующей закладке.
[/quote]
Еще раз повторюсь не должно быть автоматического закрытия почему - описал ранее.
Цитата
22. Нам не верится, что, как бы ни была велика компания, простой пользователь этой компании использует больше 10-15 сервисов и что услуг по каждому сервису больше 10. Если это так, то тут какая-то "неправильность" в каталоге или в SLA. Скорее всего, общее число услуг, которыми пользуется простой пользователь, вряд ли превосходит 50 и разбито это число еще на сервисы. Попытка выделить какие-то родовые услуги (настройка ПО совершенно различного вида), присущие нескольким сервисам, возможно и сократит общее число услуг в каталоге, но запутает ситуацию вне сомнения. Проблему со статистикой, если она есть, нужно решать, не вовлекая сюда конечного пользователя. Например, через статистку заданий или через дополнительные параметры услуг.
[/quote]
Вопрос степени зрелости процессов управления. Оптимизация каталога затруднена возможностями ПО. К примеру удалить ранее созданную услугу если к ней что-то было привязано из ряда невероятного. Было бы очень правильным реализовать возможность пересмотреть категории заявок к которым привязана услуга которую пытаются удалить.
Цитата
24. Для регистрации и обработки запросов вида MAC (Move, Add, Change) требуется особое внимание и мы планируем его уделить. Нужно ли делать какие-то специальные составные запросы и тем самым нагружать конечного пользователя – не очевидно.
[/quote]
Вот вам еще один пример правильной работы трехуровневой модели. Пользователь пишет - Прошуорганизовать рабочее место для нового сотрудника. (Обращение) Диспетчер на основании обращения генерирует комплексный запрос на изменение (RFC).
25. Внесем в список пожеланий и возможных доработок, но пока ничего обещать не могу (если выйдет то не в самых ближайших релизах)
Основная цель классификации обращений - сбор статистики для последующего анализа тенденций и управления процессом. Адекватную классификацию порой не в состоянии выполнить даже ИТ специалист не говоря уж о диспетчере. Мне например как руководителю с целью оптимизации услуг интересно видеть исходные формулировки в обращении пользователя и последующую классификацию этого обращения при привязке к инциденту (если таковая требуется). Назначение объектов типа "обращение" - автоматическая регистрация ВСЕГО что поступает на линию SD. Но не все из поступившего подлежит дальнейшей обработке. Грубо говоря если мне на SD пришло письмо с просьбой выкопать яму я его зарегистрировал (автоматически), но в дельнейшую работу не пустил ибо это за пределами моих компетенций.
Вот еще одна очень распространенная ситуация корректная реализация которой возможна только в трехуровневой модели.
Звонит мне мой руководитель и говорит, что у некоего вождя Васи срочно что-то надо сделать, я корректно отправляю его передать Васе куда надо обратиться. Но первый факт обращения уже состоялся! Как его фиксировать? Далее после внушения помощница великого Васи звонит в SD по поручению Васи после того как ему рассказали куда идти (второе обращение)... Через некоторое время, начальница секретариата звонит на SD с вопросом кагдила?(третье обращение). Все эти обращения - трудозатраты персонала SD на их обработку и параметр для аналитики мне как руководителю они нужны для анализа и отчета.
[/quote]
Во-первых, ИнфраМенеджер не мешает Вам иметь любую классификацию, в том числе и ту, что Вы описываете. Но он ограничивает конечного пользователя, если он регистрирует заявку сам. Ограничивает на верхнем уровне четырьмя вариантами, а затем ограничивает его элементами сервисов, которые доступны только этому пользователю. Так, что если ему не представлен какой-то сервис, то и заявку такую он не зарегистрирует, как бы он ни пыжился.
Во-вторых, что касается адекватности классификации, то следует различать использование классификации и собственно контроль за ее адекватностью. Классификация должна быть составлена и сопровождаться соответствующими инструкциями так, чтобы диспетчер смог ею пользоваться. Иначе действительно придется сажать рядом с ним опытного ИТ - специалиста, чтобы он классифицировал заявки. При этом никто не отменяет необходимость регулярного периодического контроля за адекватностью классификации потому, что даже самая замечательная классификация может устареть, перестать соответствовать целям и задачам организации.
Цитата
Да именно и еще проконтролировать ход исполнения и своевременность закрытия. И много чего еще. Должен и может это несколько разные понятия. Есть еще такое понятие как уровнь зрелости и невозможно с 0 подняться сразу до 3-го надо пройти ряд промежуточных этапов. Для этого требуется гибкость системы в части изменения структуры сервисов (услуг)
[/quote]
Разве имеющихся возможностей по определению сервисов недостаточно?
Цитата
А вот автоматически ничего закрываться недолжно! Где гарантия что классификация произведена верно и инцидент зарегистрированный ранее был вызван ТОЛЬКО проблемой к которой он был привязан ранее???? Где механизм контроля? На мой взгляд как минимум должна быть процедура запроса подтверждения необходимости закрыть связанные инциденты!
[/quote]
На самом деле оно так и есть - система предлагает закрыть все связанные с проблемой инциденты. Закрывать или нет - решает владелец проблемы.
Ответ на вопрос 13 будет добавлен чуть позже.
Цитата
Вопрос степени зрелости процессов управления. Оптимизация каталога затруднена возможностями ПО. К примеру удалить ранее созданную услугу если к ней что-то было привязано из ряда невероятного. Было бы очень правильным реализовать возможность пересмотреть категории заявок к которым привязана услуга которую пытаются удалить.
[/quote]
Удаление действительно требует пересмотра, согласны.
Цитата
Вот вам еще один пример правильной работы трехуровневой модели. Пользователь пишет – Прошу организовать рабочее место для нового сотрудника. (Обращение) Диспетчер на основании обращения генерирует комплексный запрос на изменение (RFC).
[/quote]
Если пользователю дать возможность формулировать описание услуг, то, как раз тогда и появятся запросы на рытье канав. Любой запрос MAC – это запрос на стандартное изменение и как стандартное изменение оно должно определяться ИТ-службой. Мы планируем сделать порождение задания на оказание такой услуги автоматическим действием, то есть совершаемым без участия диспетчера.
Все ваши высказывания справедливы для организации в которой процессы выстроены и работают, для компании в которой с этим проблемы (идет развитие) ни одно из высказываний неоднозначно. В моем случае есть более 30 прикладных программных продуктов доступ к которым предоставляется и обслуживание которых ведется ИТ подразделением, это без учета компонентов инфраструктуры. Есть сложные (с точки зрения предоставления полномочий) системы в состав которых входят более 10 компонентов требующих разграничения доступа. Если на все это наложить территориальную распределенность и зависимость качества предоставления сервиса от места его получения ( накладываются ограничения операторов связи) картина получается жуткая. С одной стороны уже сейчас для анализа трудозатрат мне необходима информация о процентном распределении запросов не только между сервисам (услугами) но и между компонентами этой услуги. С другой стороны структура каталога получается совсем ненормальная.
Возможно многие из наших затруднений связаны с отсутствием достаточной информации об идеологии, заложенной разработчиками и собственных знаний по ряду вопросов.
Тем не менее я рассматривал и рассматриваю ИМ как продукт целевая аудитория которого именно предприятия на которых в настоящий момент только начинает прорисовываться сервисный подход в управлении ИТ, т.е.: ИТ персонал знает и хочет выстроить процессы в соответствии с требованиями рекомендаций, с другой - надо выползать из существующего хаоса. Сразу это не делается, делается постепенно, пошагово. В такой ситуации бюджеты ограничены и один из продуктов отвечающий минимальным требованиям - ИМ. Соответственно должна быть гибкость в переходе от хаоса к процессной модели. На мой взгляд систем жестко зажатых рамками ITSM и стандартов огромное количество, а вот систем, позволяющих пошагово вырасти из хаоса НЕТ. Требуется продукт, позволяющий постепенным закручиванием гаек и включением дополнительных ограничений привести все в порядок но начинать надо с минимума условностей и обязательных параметров а в ИМ их ОЧЕНЬ много.
Harry33 » 10 окт 2007, 08:58 
Хм... вот так новость...