[lxa85]

Dreamer_UFA, для теории, прочтите по диагонали про ITIL, SLA.
На практике, я считаю, вам надо написать расширяемое оператором приложение.
Например определить до 5-10 уровней формализации вопроса.
Дать оператору возможность выбора не из комбо-бокса, а чего-то более большого в плане возможности отображения текстовой информации. (Т.е. в комбо-боксе два-три слова, а в Memo их с десяток). С ходу очень сложно назвать все возможные причины выхода техники из строя и причины вызова специалистов. Система должна быть расширяемой для оператора - отдельного человека, осуществляющего входной/выходной контроль информации.
Далее логично выплывают базы данных. Это и централизованное хранение запросов, резервирование информации, унификация доступа и т.д.
Это удобные запросы на выбор статистики, контроль выполнения приоритетных заявок.
В базу очень логично "подливается" кадровая информация. Т.к. запросы идут как от конкретных пользователей, так и от отделов, служб, комнат, зданий.
----
Это минимум. Далее удобные, но затратные дополнения.
Очень желательно связать с базой телефонов для уточнения заявок. Это уже сложнее т.к. базы эти как правило различны по логике. Очень здорово привязать сюда же базу техники и парка машин. Принтеров в первую очередь, т.к. замена расходников задача популярная, а читать буковки и циферки надо упрашивать. Здесь появляется возможность вести статистику учета картриджей, статистику отказа оборудования, "проблемности" отделов. Соблюдения уровня SLA, обоснование набора новых людей в штат, повышения "прозрачности" деятельности IT служб для руководства.
----
Подводные камни:
Иногда появляется большое желание распределять через эту программу задания подчиненным. Это надо делать очень аккуратно. Самое сложное - решить как именно будут мониториться заявки и задания. Либо каждые пять минут пялится в окно приложения, либо всплывающие сообщения, либо что-то еще. Тут надо думать.
Потребуется повышения ответственности сотрудников, чтобы они четко обозначали время, место и причину ухода. Это не всем по нраву. Админ существо ленивое, и подставляться просто так он не захочет. Документировать свою деятельность на серверах он вряд ли пожелает, равно как и "читать интернетики", даже с целью самообразования. К этому надо будет приучать и повышать внутреннюю дисциплину. Хорошо бы премиальной плюшкой.
----
Возвращаясь к п.2. Как отправлять заявки -- как удобней. Если получится - корпоративный чат/джабер. Письма, но с автоматическими проверялками на местах. Плюс подумать надо упрощенным доступам по ссылкам.

[Dreamer_UFA]

lxa85, Вы немного неправильно поняли. У нас внедрена корпоративная система учета заявок. Все работает прекрасно, учитываются куча факторов, SLA, различные РГ и т.д и т.п. Пользователи пишут на единый входной адрес, далее оператор спускает на ту или иную рабочу. группу. все отслеживается, мониторится, логируется, собирается статистика и все такое. Пользователь может смотреть движение своей заявки через веб интерфейс.
Я о другом...
Форма подачи. Пишут письмо на СД, но не описывая проблему подробно. Приходится отписывать уточняющие письма, ждать реакции пользователя и т.п. В силу слишком большой структуры решать проблемы он лайн не получится физически.
Я хочу написать формализатор для самого конечного пользователя, который несколькими тычками мыши отправит максимально подробную, наполненную заявку. Оператору легче, системотехникам на месте легче.
В идеале:в теме письма Наименование точки - проблема (скажем не работает АРМ), Описание : Не работает АРМ. Выдает ошибку. (скрин прилагаю). + программа сама пропинговала несколько контрольных точек, в конце дописала: Контроллер домена - доступен, ДНС - доступен и т.д.

как то так.

[lxa85]

Dreamer_UFA, тогда уточняй. Пользователи пишут письмо? Или они пишут на веб-портал допустим? Филиалы/офисы/структура имеют доступ в единую сеть? Т.е. можно будет использовать централизованную БД или нет? Мораль в том, что клиентов на местах надо будет обновлять, и при множестве различных версий это станет проблемой. Если проблема с сетью, то скорей всего заявка будет отправлена с соседнего ПК. Есть понятие база знаний, соотв. будет иметь смысл с некоторой периодичностью синхронизировать локальную базу знаний формализатора с централизованной БД.
Значит тебе необходимы: пустая графическая оболочка, с расширяемой структурой в зависимости от данных, и собственно набор данных. (xml?)
Вся "низкоуровневая работа" (пинги северов) через поток вывода, наверно можно без локального анализа (анализ на вашей админской стороне).

Более мне "на пальцах" предложить сложно.