Мы - аутсорсинговая компания, обслуживаем множество других компаний. Недавно ушли от модели, когда каждой компании соответствовал только один клиент в OTRS. Требуется совет, как поступать в некоторых случаях.
Например, наши сотрудники обнаруживают какую-либо проблему у клиента, например, не работает интернет, умер один из жестких дисков в RAID, обнаружена софтовая проблема на сервере и т.д. Часто бывает так, что мы обнаруживаем это быстрее клиентов, благодаря мониторингу, или кто-то из сотрудников выполнял работы на сервере и обнаружил проблему. Как в данном случае заносить заявки в OTRS? Ведь проблема есть и она должна быть зарегистрирована, а пользователи могут далеко не сразу ощутить воздействие проблемы и сообщить о ней.
Как быть с заявками, инициированными не клиентами?
Модератор: ykolesnikov
-
- OTRS Гуру
- Сообщения: 3119
- Зарегистрирован: 24 дек 2010, 09:27
- Откуда: Череповец
- Благодарил (а): 4 раза
- Поблагодарили: 5 раз
- Контактная информация:
Re: Как быть с заявками, инициированными не клиентами?
Добрый день!
Как вариант, раз Ваша компания - аутсорсинговая, то у нее как минимум есть выделенный, так называемый, "представитель службы заказчика", т.е ответственное лицо, с которым вы решаете и согласоываете различные вопросы. В таком случае, по предварительной договоренности с ним, Вы инициируете телефонную заявку от его имени. Он будет в курсе работы и может взаимодействовать с исполнителем. Конечно, такой вариант должен быть прописан в договоре или приложении к нему. То что идет от системы мониторинга, если она интегрирована с OTRS, будет автоматом попадать в систему через почту или другие источники. В этом случае, (тоже надо описать в договоре) основание создания заявки есть сообщение системы мониторинга. Что будет источником (клиентом) в этом случае надо смотреть как настроено и случаи (источники), также описаны в приложении к договору. В статистике по клиентам их можно выделять отдельно. Ну и еще могут быть нюансы, связанные с тарификацией Ваших услуг. Если это как-то связано с количеством заявок (предельное количество за фиксированную сумму, свыше за дополнительный пирожок, то что может вызывать споры) тут уже колдовать надо.![Улыбается :)](./images/smilies/icon_e_smile.gif)
Как вариант, раз Ваша компания - аутсорсинговая, то у нее как минимум есть выделенный, так называемый, "представитель службы заказчика", т.е ответственное лицо, с которым вы решаете и согласоываете различные вопросы. В таком случае, по предварительной договоренности с ним, Вы инициируете телефонную заявку от его имени. Он будет в курсе работы и может взаимодействовать с исполнителем. Конечно, такой вариант должен быть прописан в договоре или приложении к нему. То что идет от системы мониторинга, если она интегрирована с OTRS, будет автоматом попадать в систему через почту или другие источники. В этом случае, (тоже надо описать в договоре) основание создания заявки есть сообщение системы мониторинга. Что будет источником (клиентом) в этом случае надо смотреть как настроено и случаи (источники), также описаны в приложении к договору. В статистике по клиентам их можно выделять отдельно. Ну и еще могут быть нюансы, связанные с тарификацией Ваших услуг. Если это как-то связано с количеством заявок (предельное количество за фиксированную сумму, свыше за дополнительный пирожок, то что может вызывать споры) тут уже колдовать надо.
![Улыбается :)](./images/smilies/icon_e_smile.gif)
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
-
- OTRS Новобранец
- Сообщения: 48
- Зарегистрирован: 01 ноя 2010, 14:47
- Откуда: Воронеж
- Контактная информация:
Re: Как быть с заявками, инициированными не клиентами?
Спасибо, вариант с ответственным лицом, наверное, то что нужно. Единственное, не про все такие заявки клиенту нужно знать, а в некоторых случаях, даже нежелательно. Думаю это можно будет сделать с помощью очереди, недоступной клиентам.ykolesnikov писал(а):Добрый день!
Как вариант, раз Ваша компания - аутсорсинговая, то у нее как минимум есть выделенный, так называемый, "представитель службы заказчика", т.е ответственное лицо, с которым вы решаете и согласоываете различные вопросы. В таком случае, по предварительной договоренности с ним, Вы инициируете телефонную заявку от его имени. Он будет в курсе работы и может взаимодействовать с исполнителем. Конечно, такой вариант должен быть прописан в договоре или приложении к нему. То что идет от системы мониторинга, если она интегрирована с OTRS, будет автоматом попадать в систему через почту или другие источники. В этом случае, (тоже надо описать в договоре) основание создания заявки есть сообщение системы мониторинга. Что будет источником (клиентом) в этом случае надо смотреть как настроено и случаи (источники), также описаны в приложении к договору. В статистике по клиентам их можно выделять отдельно. Ну и еще могут быть нюансы, связанные с тарификацией Ваших услуг. Если это как-то связано с количеством заявок (предельное количество за фиксированную сумму, свыше за дополнительный пирожок, то что может вызывать споры) тут уже колдовать надо.
Интеграции с мониторингом (zabbix) у нас пока нет. Тарификация по количеству заявок также не производится.
OTRS::ITSM 5.0.5
-
- OTRS Гуру
- Сообщения: 3119
- Зарегистрирован: 24 дек 2010, 09:27
- Откуда: Череповец
- Благодарил (а): 4 раза
- Поблагодарили: 5 раз
- Контактная информация:
Re: Как быть с заявками, инициированными не клиентами?
Сделать, конечно, можно, но, это конечно, Ваше дело, но, если ввязались в это бизнес (аутсорсинг), лучше сразу строить его прозрачно. Это мое мнение. Я работал и заказчиком и аутсорсером, и у меня сложилось мнение, что свои косяки тоже нужно показывать. Это послужит и повышению доверия клиентской компании. Ведь все люди, и, если служба заказчика компетнтна, а сейчас чаще всего она строится на базе бывших ИТ-служб выводимых за пределы компаний (может это и не Ваш случай), то они (представители заказчика) знают, что абсолютно без косяков не бывает.Единственное, не про все такие заявки клиенту нужно знать, а в некоторых случаях, даже нежелательно. Думаю это можно будет сделать с помощью очереди, недоступной клиентам.
Если начнете прятать, у Вас пропадет моральное (и не только) право - строить заказчика за его косяки (сами лазили в системный блок, выковыривали застрявшую бумагу из принтера ножичком, так что печку менять надо и ...). После некоторой притирки и практики регулярных разборов таких ситуаций, возникнет доверие. А спрячете раз, два, потом вылезет и пойдут клочки по заулочкам (сам дурак, нет ты не такой..., сама дурак
![Смеется :lol:](./images/smilies/icon_lol.gif)
С уважением Юрий Колесников
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
OTRS 5.0.22, ITSM 5.0.22
OpenSuse 13.2, MariaDB 10.0.22
OTRS 5.0.22, ITSM 5.0.22 тестовая
-
- OTRS Новобранец
- Сообщения: 4
- Зарегистрирован: 11 апр 2013, 10:56
- Контактная информация:
Re: Как быть с заявками, инициированными не клиентами?
Решение из проектной практики:
Разделили инциденты на 2 разных объекта.
1 - инциденты, нарушающие доступность и качество ИТ-услуг (причем не важно кем инициирован)
2 - не нарушающие (например 1 из дисков в RAID типа "зеркало" - отказал)
Инциденты 1й группы разбили на источники. От клиента и Не от клиента. Если инцидент приходит не от клиента, но при этом нарушает качество ИТ-услуги, его регистрирует обнаруживший ИТ-специалист и привязывает к услуге.. Оповещается при этом Куратор ИТ-услуги со стороны клиента.
Инциденты 2й группы назвали сбоями и регистрировали их от имени обнаружившего ИТ-спеца или от имени системы мониторинга (автоматом), причем клиентов не уведомляли о них, т.к они не влияют на их работу и качество ИТ-услуг.
1 Важный момент
Такая схема ведет к стратегическому взаимодействию и более тесному партнерству с клиентом.
Вы открыто заявляете, что готовы работать не только в реактивном режиме, но так же проактивно реагировать на нарушения ИТ-услуг (даже когда клиент пока не заметил сбоя) .
2 Важный момент
Если схема финансовых отношений с клиентом подразумевает оплату по обращениям - то эта схема работать не будет. Клиент будет возмущен ростом обращений, без его иннициативы.
Взаимодействие такого рода, должно вести к схеме типа абонентской плате за качественно предоставленные ИТ-услуги.
Более подробные комментарии готов выдать голосом, т.к нюансов много.
skype: infras0und
Разделили инциденты на 2 разных объекта.
1 - инциденты, нарушающие доступность и качество ИТ-услуг (причем не важно кем инициирован)
2 - не нарушающие (например 1 из дисков в RAID типа "зеркало" - отказал)
Инциденты 1й группы разбили на источники. От клиента и Не от клиента. Если инцидент приходит не от клиента, но при этом нарушает качество ИТ-услуги, его регистрирует обнаруживший ИТ-специалист и привязывает к услуге.. Оповещается при этом Куратор ИТ-услуги со стороны клиента.
Инциденты 2й группы назвали сбоями и регистрировали их от имени обнаружившего ИТ-спеца или от имени системы мониторинга (автоматом), причем клиентов не уведомляли о них, т.к они не влияют на их работу и качество ИТ-услуг.
1 Важный момент
Такая схема ведет к стратегическому взаимодействию и более тесному партнерству с клиентом.
Вы открыто заявляете, что готовы работать не только в реактивном режиме, но так же проактивно реагировать на нарушения ИТ-услуг (даже когда клиент пока не заметил сбоя) .
2 Важный момент
Если схема финансовых отношений с клиентом подразумевает оплату по обращениям - то эта схема работать не будет. Клиент будет возмущен ростом обращений, без его иннициативы.
Взаимодействие такого рода, должно вести к схеме типа абонентской плате за качественно предоставленные ИТ-услуги.
Более подробные комментарии готов выдать голосом, т.к нюансов много.
skype: infras0und
Антон Алексеев
===
ITSM- фарватер к эффективному и зрелому провайдеру ИТ-услуг
ITIL- сборник лоций, с примерным описанием пункта назначения, и сложностями на маршруте
ITSM-консультант- шкипер
-ITSMART--искусство настройки такелажа, школа моряков и опытные шкиперы
===
ITSM- фарватер к эффективному и зрелому провайдеру ИТ-услуг
ITIL- сборник лоций, с примерным описанием пункта назначения, и сложностями на маршруте
ITSM-консультант- шкипер
-ITSMART--искусство настройки такелажа, школа моряков и опытные шкиперы