Помогите определиться со структурой

[mukexa]

Здравствуйте. Во-первых хочу поздравить всех с наступающими праздниками! Хорошего вам настроения как во время праздников так и после них!

И так теперь по сути вопроса. Как говорил мой инструктор по вождению - лучше научить чем переучивать ) Почитал немного форум и понял, что большинство просьб помочь подстроить OTRS под свой бизнес-процесс. В итоге рекомендуют сменить всё таки последнее. Так вот хочу попросить вас наставить меня на путь истинный, а именно построить структуру.
Что имеем:
1. Мы производители ПО для аптек. Как одиночных так и сетей.
Что я делаю - создаю клиентов(аптечные пункты по факту) и использую одинаковый идентификатор(ID) внутри конкретной сети, что позволяет соорудить структуру компаний.

2. Службу тех.поддержки по всей стране(региональные представительства). Сейчас работаем в хаотическом режиме. То есть региональные представители бросают проблему в скайповый чат и там им пытаются помочь. Соответственно толковой истории задачи нету и много одинаковых проблем которые циклически приходится решать. На плечах технических специалистов (ТСов) лежат задачи установки, обучения и поддержки клиентов. А иногда и поиск этих самых клиентов. Понятно, что в определённый момент человек исчерпает свои ресурсы(время, силы, здоровье) Потому мы решили немножко облегчить их жизнь и создать "колцентр" который по сути будет так же "Service Desk".
Что я делаю - создаю агентов, пока все будут в группе "users". И потихоньку буду разбираться с группами/ролями.
Агенты, если не могут решить самостоятельно проблему назначают "ответственного", одного из ведущих ТСов.

3. Так как мы развиваем наш продукт, то он имеет "версионность". Вот этот вопрос и хотелось бы обсудить более детально.
Развернул следующую цепочку:
-ПК Аптека
-- 2.33
--- 2.33.3
----2.33.4.2
-- 2.34
Но когда перешел в Заявки/Просмотр очереди увидел "ПК Аптека (4)", но в таблице пусто так как и в "2.33 (4)". Часть заявок было привязано к 2.33.3 и часть к 2.33.4.2. То есть, я не увидел какого-то свода, нужно заходить в каждую "под очередь" и просматривать чего же там делается. Как быть? Есть ли какая настройка чтобы видеть все заявки подгрупп в группе?
Нам нужно в итоге знать количество заявок/инцидентов по конкретному релизу, может есть иные предложения?

4. Хотелось бы привязать к каждому клиенту ответственного агента, даже двоих, а то и троих - "продажник", "ТС" и "ведущий ТС региона". Не сервис, а именно агентов.
Я так понимаю нужно добавить динамическое поле, которое будет отображать список агентов(в будущем только агентов группы "ТС") и в нём выбирать ответственного. Возможно по этому полю автоматически будет выбираться "владелец"(ТС) и "ответственный"(ведущий ТС) заявки.

Жду ваших комментариев и простите за "много буковок" ) Половину вопросов решил при написании, так наверное легче анализировать )

[alexus]

Самое первое и самое важное: очереди надо строить не по клиентам, а по организационно-функциональной структуре вашей поддержки. Например:

1-я линия ServiceDesk

2-я линия
2-я линия::Центр
2-я линия::Регион 001
2-я линия::Центр::Ваш Продукт - ТС
2-я линия::Центр::Ваш Продукт - Модуль 1
2-я линия::Центр::Ваш Продукт - Модуль 2 - здесь имеет смысл деление, если за поддержку разных модулей отвечают разные специалисты
2-я линия::Регион 001::Ваш Продукт - ТС
2-я линия::Регион 001::Ваш Продукт - Модуль 1
2-я линия::Регион 001::Ваш Продукт - Модуль 2 - здесь имеет смысл деление, если за поддержку разных модулей отвечают разные специалисты

3-я линия::Ваш Продукт - Разработчики - это когда уже не помогают консультации, а надо править баги, тикет прилетает сюда.

Продажи - отдельная очередь. Можно тоже делить по регионам.

Версии продуктов лучше всего хранить в динамических полях. Тогда по ним и получите выборку тикетов.
А сами продукты и доп услуги объявить сервисами.

Ответственных использовать не рекомендую для вашего случая. Только если Вы не хотите, чтобы ваш колл-центр(он же сервисдеск) повесился через 2 недели из-за количества висящих на них тикетов. Просто поверьте, а поймете потом !

Хотелось бы привязать к каждому клиенту ответственного агента, даже двоих, а то и троих - "продажник", "ТС" и "ведущий ТС региона". Не сервис, а именно агентов.

И как Вы будете определять из какого региона тикет пришел?
Персональные агенты - это, конечно, круто, но не эффективно. Денег хватит на зарплату ?

Я так понимаю нужно добавить динамическое поле, которое будет отображать список агентов

Нет такого динамического поля.

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

[mukexa]

Нет, нет... Не подумайте, не забросил ) Обдумываю Ваши замечания и предложения. Параллельно изучаю саму систему.

Персональные агенты - это, конечно, круто, но не эффективно. Денег хватит на зарплату ?

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

Версии продуктов лучше всего хранить в динамических полях. Тогда по ним и получите выборку тикетов.

В таком случае будет целая лента версий, продукт развивающийся и имеет тенденцию к багам(сменилась команда разработчиков). Посему порождаются "подверсии/патчи". Удалять из дин.полей то можно, но реально будет топом построить отчет за старые релизы?

скатились в настройку OTRS

Ну хотелось показать, что всё таки читал мануал. Но оказалось наоборот, нужно было об этом молчать )

Относительно версионности:
....
2.33.0
2.33.3
2.33.4
2.33.4.1
2.33.4.2 - актуальная
2.33.5 - бета тестирование
....
Относительно нынешней структуры поддержки:
_________________________Начальник тех.поддержки
___________Ведущий ТС Региона_______________Ведущий ТС Региона
______ТС____ТС____ТС_____________________________ТС________________ТС
__Клиент__Клиент__Клиент_______________________Клиент_________Клиент__Клиент
ТС принимает звонок от клиента и пытается решить вопрос самостоятельно. Если не может - обращается по ступени выше и тд. Если "Ведущий ТС" видит, что проблема серьезная и нужно быстрое решение, может сам забрать заявку.
Новая версия сводится к тому, что хотим меж ТС и клиентом всунуть "колл-центр":
_________________________Начальник тех.поддержки
___________Ведущий ТС Региона_______________Ведущий ТС Региона
______ТС____ТС____ТС_____________________________ТС________________ТС
------------------------------------------- Колл-центр --------------------------------------------
__Клиент__Клиент__Клиент_______________________Клиент_________Клиент__Клиент
На плечи "колл-центра" ложится ответственность за принятие заявки и по возможности её решение(мелкие консультации).

Услуги предоставляем исключительно на консультирование нашего ПО. Никаких ремонтов, настроек ОС и тд. Если клиент и просит, а ТС в силе это сделать, то это остаётся меж ними(халтура).

Связь с отделом программирования будет через тестировщика. У них своя тикетная система, в которую нас пускать не планируют. В итоге если всплывает баг, то раз в день тестировщик просматривает их и если подтверждается, то создаётся тикет в их системе, а в заявке указывается ссылка на него(для нас "ридонли"). Тупость, потому как кому-то нужно следить за их тикетом и в случае успешного закрытия закрывать у себя. Но как есть.

Пока крутил сделал вот такую штуку :

Снимок.PNG (12.65 КБ) 4599 просмотров

Думаю удобней проходиться по очереди поля нежели из настроек добавлять клиента, а потом опять возвращаться вверх к "очереди" и "владельцу".
Пойду размышлять дальше, ночка длинная )
Удачи всем!