Доброго времени суток.
Прошу помощи у уважаемого IT сообщества.
Есть множество удаленных и не очень точек которые мы обслуживаем. Для работы с заявками на обслуживание используем некий Service Desk портал. Пользователи пишут на единый входной адрес, потом система либо оператор переводит заявку в какую либо рабочую группу. Ну это так, предисловие.
Большинство пользователей не затрудняют себя наполнением заявки а просто лишь бы отписать. Пример: Тема- проблема с принтером Текст- не работает принтер. Помогите!!!
Вот и сиди, думай что за проблема, в чем выражается...
Возможно с принтером пример не совсем удачный, тем не менее суть ясна.
Пишу формализатор заявок. Ничего не надо писать, выбрать из ComboBox`ов то что нужно, дописать примечание и нажать кнопку Отправить.
В системе появится сообщение: Тема - Точка 1 : Проблема с принтером, далее в теле письма типичные проблемы.
1. Не хочу плодить кучу боксов. Как сделать допустим что бы для каждого выбора в 1 боксе - во втором были описаны проблемы только конкретно выбранного элемента ?
2. Что лучше, отправлять из самой программы (Indy) либо подготовить письмо и отправлять через WinApi стандартным почтовиком (mailto) - ?
3. Как можно организовать контроль за заявками ? Что бы можно было посмотреть количество и текст отправленных заявок скажем за неделю....
простите за сумбурность.... если вопросы будут отвечу. пока все на эмоциях..
ЗЫ: Прикрепил рисунок, может яснее будет. В общем для каждого значения ComboBox1 - свои значения ComboBox2
Delphi - [решено] Формализатор заявок
-
lxa85
Re: Delphi - [решено] Формализатор заявок
Dreamer_UFA, для теории, прочтите по диагонали про ITIL, SLA.
На практике, я считаю, вам надо написать расширяемое оператором приложение.
Например определить до 5-10 уровней формализации вопроса.
Дать оператору возможность выбора не из комбо-бокса, а чего-то более большого в плане возможности отображения текстовой информации. (Т.е. в комбо-боксе два-три слова, а в Memo их с десяток). С ходу очень сложно назвать все возможные причины выхода техники из строя и причины вызова специалистов. Система должна быть расширяемой для оператора - отдельного человека, осуществляющего входной/выходной контроль информации.
Далее логично выплывают базы данных. Это и централизованное хранение запросов, резервирование информации, унификация доступа и т.д.
Это удобные запросы на выбор статистики, контроль выполнения приоритетных заявок.
В базу очень логично "подливается" кадровая информация. Т.к. запросы идут как от конкретных пользователей, так и от отделов, служб, комнат, зданий.
----
Это минимум. Далее удобные, но затратные дополнения.
Очень желательно связать с базой телефонов для уточнения заявок. Это уже сложнее т.к. базы эти как правило различны по логике. Очень здорово привязать сюда же базу техники и парка машин. Принтеров в первую очередь, т.к. замена расходников задача популярная, а читать буковки и циферки надо упрашивать. Здесь появляется возможность вести статистику учета картриджей, статистику отказа оборудования, "проблемности" отделов. Соблюдения уровня SLA, обоснование набора новых людей в штат, повышения "прозрачности" деятельности IT служб для руководства.
----
Подводные камни:
Иногда появляется большое желание распределять через эту программу задания подчиненным. Это надо делать очень аккуратно. Самое сложное - решить как именно будут мониториться заявки и задания. Либо каждые пять минут пялится в окно приложения, либо всплывающие сообщения, либо что-то еще. Тут надо думать.
Потребуется повышения ответственности сотрудников, чтобы они четко обозначали время, место и причину ухода. Это не всем по нраву. Админ существо ленивое, и подставляться просто так он не захочет. Документировать свою деятельность на серверах он вряд ли пожелает, равно как и "читать интернетики", даже с целью самообразования. К этому надо будет приучать и повышать внутреннюю дисциплину. Хорошо бы премиальной плюшкой.
----
Возвращаясь к п.2. Как отправлять заявки -- как удобней. Если получится - корпоративный чат/джабер. Письма, но с автоматическими проверялками на местах. Плюс подумать надо упрощенным доступам по ссылкам.
На практике, я считаю, вам надо написать расширяемое оператором приложение.
Например определить до 5-10 уровней формализации вопроса.
Дать оператору возможность выбора не из комбо-бокса, а чего-то более большого в плане возможности отображения текстовой информации. (Т.е. в комбо-боксе два-три слова, а в Memo их с десяток). С ходу очень сложно назвать все возможные причины выхода техники из строя и причины вызова специалистов. Система должна быть расширяемой для оператора - отдельного человека, осуществляющего входной/выходной контроль информации.
Далее логично выплывают базы данных. Это и централизованное хранение запросов, резервирование информации, унификация доступа и т.д.
Это удобные запросы на выбор статистики, контроль выполнения приоритетных заявок.
В базу очень логично "подливается" кадровая информация. Т.к. запросы идут как от конкретных пользователей, так и от отделов, служб, комнат, зданий.
----
Это минимум. Далее удобные, но затратные дополнения.
Очень желательно связать с базой телефонов для уточнения заявок. Это уже сложнее т.к. базы эти как правило различны по логике. Очень здорово привязать сюда же базу техники и парка машин. Принтеров в первую очередь, т.к. замена расходников задача популярная, а читать буковки и циферки надо упрашивать. Здесь появляется возможность вести статистику учета картриджей, статистику отказа оборудования, "проблемности" отделов. Соблюдения уровня SLA, обоснование набора новых людей в штат, повышения "прозрачности" деятельности IT служб для руководства.
----
Подводные камни:
Иногда появляется большое желание распределять через эту программу задания подчиненным. Это надо делать очень аккуратно. Самое сложное - решить как именно будут мониториться заявки и задания. Либо каждые пять минут пялится в окно приложения, либо всплывающие сообщения, либо что-то еще. Тут надо думать.
Потребуется повышения ответственности сотрудников, чтобы они четко обозначали время, место и причину ухода. Это не всем по нраву. Админ существо ленивое, и подставляться просто так он не захочет. Документировать свою деятельность на серверах он вряд ли пожелает, равно как и "читать интернетики", даже с целью самообразования. К этому надо будет приучать и повышать внутреннюю дисциплину. Хорошо бы премиальной плюшкой.
----
Возвращаясь к п.2. Как отправлять заявки -- как удобней. Если получится - корпоративный чат/джабер. Письма, но с автоматическими проверялками на местах. Плюс подумать надо упрощенным доступам по ссылкам.
-
Dreamer_UFA
Re: Delphi - [решено] Формализатор заявок
lxa85, Вы немного неправильно поняли. У нас внедрена корпоративная система учета заявок. Все работает прекрасно, учитываются куча факторов, SLA, различные РГ и т.д и т.п. Пользователи пишут на единый входной адрес, далее оператор спускает на ту или иную рабочу. группу. все отслеживается, мониторится, логируется, собирается статистика и все такое. Пользователь может смотреть движение своей заявки через веб интерфейс.
Я о другом...
Форма подачи. Пишут письмо на СД, но не описывая проблему подробно. Приходится отписывать уточняющие письма, ждать реакции пользователя и т.п. В силу слишком большой структуры решать проблемы он лайн не получится физически.
Я хочу написать формализатор для самого конечного пользователя, который несколькими тычками мыши отправит максимально подробную, наполненную заявку. Оператору легче, системотехникам на месте легче.
В идеале:в теме письма Наименование точки - проблема (скажем не работает АРМ), Описание : Не работает АРМ. Выдает ошибку. (скрин прилагаю). + программа сама пропинговала несколько контрольных точек, в конце дописала: Контроллер домена - доступен, ДНС - доступен и т.д.
как то так.
Я о другом...
Форма подачи. Пишут письмо на СД, но не описывая проблему подробно. Приходится отписывать уточняющие письма, ждать реакции пользователя и т.п. В силу слишком большой структуры решать проблемы он лайн не получится физически.
Я хочу написать формализатор для самого конечного пользователя, который несколькими тычками мыши отправит максимально подробную, наполненную заявку. Оператору легче, системотехникам на месте легче.
В идеале:в теме письма Наименование точки - проблема (скажем не работает АРМ), Описание : Не работает АРМ. Выдает ошибку. (скрин прилагаю). + программа сама пропинговала несколько контрольных точек, в конце дописала: Контроллер домена - доступен, ДНС - доступен и т.д.
как то так.
-
lxa85
Re: Delphi - [решено] Формализатор заявок
Dreamer_UFA, тогда уточняй. Пользователи пишут письмо? Или они пишут на веб-портал допустим? Филиалы/офисы/структура имеют доступ в единую сеть? Т.е. можно будет использовать централизованную БД или нет? Мораль в том, что клиентов на местах надо будет обновлять, и при множестве различных версий это станет проблемой. Если проблема с сетью, то скорей всего заявка будет отправлена с соседнего ПК. Есть понятие база знаний, соотв. будет иметь смысл с некоторой периодичностью синхронизировать локальную базу знаний формализатора с централизованной БД.
Значит тебе необходимы: пустая графическая оболочка, с расширяемой структурой в зависимости от данных, и собственно набор данных. (xml?)
Вся "низкоуровневая работа" (пинги северов) через поток вывода, наверно можно без локального анализа (анализ на вашей админской стороне).
Более мне "на пальцах" предложить сложно.
Значит тебе необходимы: пустая графическая оболочка, с расширяемой структурой в зависимости от данных, и собственно набор данных. (xml?)
Вся "низкоуровневая работа" (пинги северов) через поток вывода, наверно можно без локального анализа (анализ на вашей админской стороне).
Более мне "на пальцах" предложить сложно.