Схема работы.

[JohniGo]

Хочу поделиться размышлениями на тему организации механизма работы техподдержки. Есть желание организовать работу таким образом, но пока нет четкого понимания, как добиться подобного в OTRS.

Вводные данные.
Система предназначена для автоматизации работы ИТ отдела организации. Все сотрудники являются клиентами. ИТ отдел состоит из техподдержки, администраторов и программистов, занимающихся поддержкой используемого в организации ПО (все стандартно). В организации развернут домен Windows.
Настраиваю OTRS 3.0.1

Механизм работы.
1. Определяем и согласовываем с руководством перечень сервисов (в понятной для них форме), которые предоставляет ИТО всем сотрудникам оргнизации. Устанавливаем максимально допустимое время простоя для каждого из сервисов. (SLA)
2. Любой сотрудник может зайти на сайт техподдержки и оставить заявку об инциденте (в дальнейшем и RFC и т.д. по ITIL) по какому-либо сервису. При этом авторизация сквозная из домена (SSO).
3. Исходя из SLA и серрвиса, к которому относится инецидент, у завки должны проставиться соответвующие поля по срокам первого ответа, эскалации и решения инцидента. Предполагаю приявзать сразу и CMDB, но пока модуль ITSM не доступен. Ждем февраля 2011 (если я правильно помню план разработчиков).
4. Все завки в первую очередь попадают в техподдержку, которая пытается их решить своими силами и, если это выходит за рамки их компетенци передает на следующий уровень - профильному специалисту.
5. Жизненный цикл заявки: Новая - Открыта - Решена - Закрыта. При этом сотрудники ИТО не должны иметь возможность закрывать заявки сами. При статусе "Решена", заявка ставится в очередь на автозакрытие (ну скажем на день). За это время клиент должен либо подтвердить решание проблемы и закрыть заявку вручную, либо вернуть ей статус "Открыта". В противном случае. если клиент не отреагировал на уведомление о решении, проблема считается решенной и заявка закрывается автоматически. Соответсвенно замеряется всремя между переходом заявки из состояния "Новая" в состояние "Решена" (последним).
Собственно этим я хочу добиться минимизации работы техподдержки по выяснению обратной связи от клиентов, т.к. отдельного человека на это нет. С другой стороны, гарантировано получить подтверждение решения проблемы от клиента.

Покритикуйте такую схему. Можно ли ее полностью реализовать средствами OTRS или с добавлением модуля ITSM.

Сделано
1. Клиенты авторизуются через NTLM, данные клента берутся из AD серез LDAP.
2. Агенты авторизуются по LDAP через группы AD.
3. Для каждого направления (техподдержка, сисадмин, 1С, web и даже нач.ИТО) созданы отдельные группы и очереди.
4. Для клиентов включены группы и дан доступ во все группы (дабы могли переписываться со специалистами при перемещении заявок в их очереди).
5. В новой заявке скрыт выбор очереди и по умолчанию настроена очередь "Техподдержка".

Собственно вопрос встал как раз в организации предполагаемой схемы работы. Как правильно раздать права и настроить систему, чтобы получить желаемый результат?
Буду рад любым контруктивным предложениям и замечаниям.

[alexus]

Не вдаваясь в детали, можно сказать, что схема работы хотя и сильно упрощена (иногда это очень хорошо!), но выстроена неплохо. Все это, в основном, OTRS может сделать! Хотелось бы понять, а что на данный момент не получается сделать?

[JohniGo]

Если бы на пальцах расписали планчик как этого добиться... Пока не могу понять с какого конца взяться.
А в чем упрощенность (я тоже думаю, что простота - хороше свойство механизма)? Я понимаю, что после запуска вработу наверняка всплывут нюансы, которы я с пока в схеме не предусмотрел.
Если можно, "вдайтесь в детали", хотя бы не очень глубоко. В самые, так сказать, лежащие на поверхности.

Хотелось бы понять, а что на данный момент не получается сделать?

Например механиз автоматизации SLA и сроков для завки - не знаю как сделать.
Как отразится отключение некоторых статусов на механизме работы (и отчетов соответсвенно) и как правильно добавить свой статус заявки "решена".
Как лишить агентов права закывать заявки самостоятельно.
Да и автозакрытие при установке 3.0.1 "из коробки" не работает. Очевидно надо настраивать задание.
Что-то даже уведомления на почту не шлет... (как вчера выяснилось)... 2.4.7 вроди без дополнительных настроек отправлял...

Я по первости замахнулся сразу и ITSM настраивать, но понял, что не осилю. Надо постепенно..

[alexus]

Все вопросы которые Вы задаете, относятся не к ОТРС, а методике внедрения ITSM-процессов (IM, ChM, ServiseDesk, SLM, PrM). ОТРС - лишь средство автоматизации того, что вы спланировали-спроектировали. Вам нужен либо консалтинг по ИТСМ либо самообразование в данной области (ITIL, ITSM и т.п.). Первый вариант стоит хороших (или очень хороших) денег, в зависимости от размера вашей ИТ-службы, второй вариант тоже стоит денег, но меньших, но он длиннее по времени. Мы оказываем услуги по консалтингу для малых ИТ-служб для комплексных проектов и для отдельных процессов. Советом помочь можно и в рамках форума.

[JohniGo]

Мы оказываем услуги по консалтингу для малых ИТ-служб для комплексных проектов и для отдельных процессов.

...ради рекламы которых данный форум собственно и организован...
Ладно, в таком случае пойду перечитывать "Введение в ITSM"... Меня сбило с толку название раздела... Спасибо за участие...

[alexus]

В ближайших планах этот форум, скорее всего станет частью otrs.com или org. Думаю, там Вам некого будет упрекать в рекламе
По поводу "Введения в ITSM" - очень правильная мысль. Могу порекомендовать курсы компании "Cleverics" Это тоже суперреклама! Я сам там учился, и всем кто спросит, рекомендовал и буду рекомендовать!. Напишите в личку, поделюсь еще другими материалами по ITSM.
Поймите правильно, но сейчас Ваши вопрос стоит так: "Запустите мне ITSM на OTRS". А это серьезный проект, который бесплатно только Вы сами сделаете, да и то условно-бесплатно.
Думаю, что этот раздел все-таки будет развиваться, но готовых "на блюдечке" проектов Вы ни здесь, ни где либо скорее всего не найдете.
Пришлите мне в личку свои контакты и описание Вашей организации и ИТ-службы и мы можем рассмотреть вариант пилотного "маркетингового внедрения" на взаимоинтересных условиях.

[JohniGo]

Ни коим образом не осуждаю Ваше законное желание заработать. Более того, я рассматривал возможность привлечения консультантов для решения данной задачи, но по некоторым причинам, отказался от этой идеи. Собственно если бы такое решение и было принято, то я разместил бы об этом недвусмысленное сообщение.
Если Вы считаете свои знания слишком ценными, чтобы делиться ими бесплатно, Ваше право. Однако если уж разговор идет о консалтиге, то с точки зрения рекламы серия Ваших статей по базовой настройке OTRS (а то что я спросил, это имено базовая настройка, это даже не полноценный IM, не говоря уж о "Запустите мне ITSM" ) была бы очень выигрышна с точки зрения рекламы. Как Вы считаете? Можно подискутировать на тему консалтинга в нашем "постсовком ИТ", мне это тоже интересно, однако к теме данного раздела это не имеет отношения. Создавая данный топик я надеялся на некую полезную для внедрения ITSM дискуссию. К сожалению, никакой полезной информации я пока для себя не почерпнул.
Если у Вас есть желание поделиться какими-то наработками или материалами по ITSM в целом или настроке OTRS, как одной из его реализации - выкладывайте. Думаю не только я, а очень многие будут Вам за это благодарны.

[alexus]

Предлагаю перевести дискуссию в более конструктивное русло. Как вам, например, такой вариант: сделайте топик "Как мы внедряем OTRS - On-line Проект", и укажите постановку задачи с начальными входными данными без раскрытия коммерческой или секретной (а вдруг ) информации. Далее надо примерно описать план действий и достигнутые результаты. Укажите проблемные участки. Думаю комментарии не заставят себя ждать. Это и Вам и всем будет весьма полезно. Мне кажется, что я несколько ошибся в первоначальной оценке Ваших вопросов, в чем собственно и признаюсь.
Что касается статей по базовой настройке, то я не верю в продукт ИТСМ "из коробки", т.к. каждая ИТ-служба несчастна по-своему . Хотя некоторые вещи, возможно, стоит описать. Доп. материалы будут выкладываться после запуска полноценного сайта. Не форумом же единым жить... На данный момент процесс в стадии переговоров о дружественных отношениях OTRS AG.

[JohniGo]

Хорошая мысль. Попробую на выходных преобразовать этот топик во что-то подобное.

[alexus]

Может сделаете новый, а этот я закрою?

[JohniGo]

Да, конечно. Я имел в виду, что соберу из этого топика осмысленную инфу.

[alexus]

Какие будут дальнейшие действия?

[JohniGo]

К сожалению, жестокий завал по времени. Занимаюсь системой очень урывочно.. поэтому и не начал обещанный топик..

[kaa]

JohniGo, как дела? Кой-какие соображения у меня есть по этой теме. Но она старая. Актуально еще?

[JohniGo]

Велкам.
Внедрение идет потихонечку. Все никак не соберусь оформить отдельным топиком.
Пока пытаюсь довести до ума управление инцидентами (приучить сотрудников, определиться с анализом), частично настроили CMDB и потихоньку сомтрю "Управление проблемами".
Внедрение сильно сдерживает отсутвие мануала по пакету ITSM.

[kaa]

5. Жизненный цикл заявки: Новая - Открыта - Решена - Закрыта. При этом сотрудники ИТО не должны иметь возможность закрывать заявки сами. При статусе "Решена", заявка ставится в очередь на автозакрытие (ну скажем на день). За это время клиент должен либо подтвердить решание проблемы и закрыть заявку вручную, либо вернуть ей статус "Открыта". В противном случае. если клиент не отреагировал на уведомление о решении, проблема считается решенной и заявка закрывается автоматически. Соответсвенно замеряется всремя между переходом заявки из состояния "Новая" в состояние "Решена" (последним).
Собственно этим я хочу добиться минимизации работы техподдержки по выяснению обратной связи от клиентов, т.к. отдельного человека на это нет. С другой стороны, гарантировано получить подтверждение решения проблемы от клиента.

Это получилось?

Если нет, то есть немного другая схема. Агенты закрывать заявку могут, настраиваем уведомление клиенту о закрытии.
Там говорим закрыта с таким то статусом таким-то человеком. Если не согласны - просто ответьте на данное письмо.
Система при получении письма сделает follow up тикета, а в истории инцидента это все будет отражено. Соответственно не будет докручиваться лишних суток к решению заявки

Тут мы тему уведомления о закрытии обсуждали:
viewtopic.php?f=5&t=148

[ykolesnikov]

Думаю, это правильная схема. Клиент должен закрывать заявку только по своей инициативе, если надобность отпала (обнаружил, что силовой кабель не был включен в розетку).
А в норме - агент закрывает заявку - сообщение/уведомление клиенту. Если тот не согласен - отвечает и заявка открывается вновь. Ведь у клиента никогда нет стимула что-то делать, если инцидент исчерпан. Более того особо вежливые будут писать - "спасибо", но забудут указать - "Закрыта успешно" и заявка вновь откроется.

[JohniGo]

Да все работает. Статус "закрыта успешно" стоит у клиента в интерфейсе по умолчанию. А статистику мерять можно хоть до состояния "закрыта", хоть до "решена". Разницы на самом деле нет. Кстати думаю над тем, чтобы еще и тип статуса "уточняется" добавить.
Вариант с уведомлением о закрытии тоже хороший, правда там очевидно необходимо не просто ответить на письмо, а и написать, в чем теперь проявляется проблема (предполагается, что техподдержка добросовестно проверила писанные в заявке симптомы и вылезло что-то новое).
В письме заставить это сделать человека не возможно, а вебе - вполне.
В общем-то я пока даже не готов отстаивать свою схему, пока устраивает, посмотрю, есть ли смысл переделывать.
Собственно пользователи с трудом привыкают к тому, что можно и в ответ на заметку "решена" написать, "нет не работает" и поставить снова "открыта".
Ни мануалы, ни описание в тексте уведомления не помогают. Видимо надо все-таки организовывать массовый сеанс гипноза (обучения).

[ykolesnikov]

Учить, конечно, надо. Клиент ленив, по определению и мануалы читать не любит, хоть их комиксами начинить. Длинно и неинтересно, на второй странице, голова падает. Руководитель клиента, зачастую, тоже не склонен ему по лбу настучать, что неправильно работает, легче позвонить и сказать ИТ-шефу - "опять твои накосячили, не хотят заявку принимать...", а тот еще вместо того, чтобы послать его в...техподдержку, начинает своих дрючить...Проходили. Надо как японцы - утром в начале дня - дал присягу соблюдать правила ТБ и все. Случилось что - не мастер виноват, как у нас - а ты родной, ты ж присягу давал. Провести курсы обучения под роспись, потом про все неправильные действия - разбор полетов и начисление "бонусов"

[alexus]

Вообще вопрос "дрессировки" пользователей насколь важен, настоль и сложен. Тут надо идти двумя путями. Во-первых, стремиться сделать "интерфейс" с ИТ максимально удобным и полезным. Во-вторых, конечно, надо договариваться с заказчиком о разграничении ответственности по границе "тупость юзера-забой ИТ".

[kaa]

Уважаемые дамы и господа!
Вопрос по схеме. простой вроде.
Агентам поставил права ro на группу, группу привязал к очереди. Если заявка заблокирована на кого-то, то другой изменений внести не может - мне это подходит.

Но если заявка разблокирована, то любой агент может вносить любые изменения. В итоге агенты работают с неблокированными заявками и непонятно кто конкретно занимается заявкой.

Можно ли сделать так, чтобы полный спектр действий с заявкой становился доступным агенту только после блокировки?

[yuri0001]

Под рукой сейчас системы нет, но если не изменяет память, посмотрите параметры типа BlockRequired для разных экранов. Любое действие будет блокировать заявку. Ну, а если агенты такие расхлябанные - анализируйте работу регулярно и раздавайте "пирожки с полочки"

[kaa]

Под рукой сейчас системы нет, но если не изменяет память, посмотрите параметры типа BlockRequired для разных экранов.

К сожалению не нашел такого параметра. Искал просто по шаблону block* - также ничего интересного не дало. Есть еще идеи?

[yuri0001]

Память моя, память - русский - английский - LockRequiured, конечно же

[kaa]

Edit Config Settings in Ticket -> Frontend::Agent::Ticket:: и тут дофига

Ключевое слово поиска RequiredLock

Спасибо! за подсказку, буду разбираться, но логика понятна.