Валерий Фокин пишет:
каким образом, при наличии двух аппликов сделать так, чтобы правила бизнес-логики работали только на одном? А второй только отрабатывал пользовательские сессии
UI правила в любом случае будут отрабатывать на том app, к которому подключен пользователь. Можно лишь добиться того, чтобы все scheduled tasks, что по сути есть часть DB rules работали на одном app-сервере. Как это сделать я пока не знаю. Копаю в следующую сторону - scheduled tasks хранятся в таблице rep_javaobjects. Нужно понять каким образом app формирует записи в поле jav_instance - возможно поможет декомпиляция системных классов.
Григорий Ненашев пишет:
На какой продукт не посмотришь везде свои как плюсы так и минусы, а вот чтобы хоть кто ни будь, смог повторить весь функционал 4.5 я еще не видел.
Omnitracker. Админить немного тяжелее, но гораздо больше новых возможностей и фишек. Интересная система.
HP Service Manager. Дорогой, поддержка трудозатратна, но на его платформе можно реализовать вообще все что в голову придет.
Большое количество правил по работе с эскалациями приводит к большим проблемам.
Большое количество это какое? Может ли считаться с вашей точки зрения большим количеством ~5000 scheduled tasks (~800 на app)?
Решали ли когда-нибудь проблему с блокировкой ресурсов (таблиц) на уровне БД?
Мне кажется, вам подойдет вариант, когда специалисты будут сами выставлять свои трудозатраты.
Например, так:
1. Создать поля: текст(4000), поле строка(256),2 поля с временем (формат чч:мм) - рабочее время, нерабочее время.
2. При выполнении каких-либо работ инженер записывает свой комментарий в поле строка(256), ставит количество потраченного времени в одно из полей (рабочее время, нерабочее время)
3. При сохранении запроса\рабочего задания текст из строки, время, ФИО добавляется в поле текст(4000), время суммируется с общими трудозатратами.
4. Триггер в БД добавляет данные в специальную таблицу, которая используется для формирования отчета о трудозатратах.
Каждый раз когда кто-то задумывает сделать 100% верную систему учета рабочего времени, сталкиваются с одними и теми же проблемами: недостаточные возможности средств автоматизации, человеческий фактор при списании трудозатрат, трудности в регламентации и описании стандартных действий.
Обычно при решении этой задачи следуют одним из 3-х путей, соответственно: тотальное слежение\журналирование каждого чиха сотрудника, предоставление сотруднику возможности самому отчитываться о своих трудозатратах и загрузке, составление некого списка стандартных операций с типовыми решениями и регламентированным временем выполнения этих операций. Естественно категории сотрудников бывают разные и для всех будут свои KPI.
У нас, например, для инженерного состава организации эта задача решена следующим образом:
Сотрудники все свои действия в рамках запросов\инцидентов записывают в запрос\инцидент с указанием потраченного времени. Далее эта информация заносится в БД, откуда выгружается различными аналитическими отчетами. В том числе, сверяется с данными системы контроля и учета доступа в офисе. Вся эта аналитика непосредственно завязана на мотивацию - премии.
В вашем случае считаю возможно внедрить 3 варианта - заставить людей указывать свои трудозатраты, попробовать поколдовать с механизмами SLA для расчета рабочего времени, пересчитывать триггером в БД рабочее время на основе тех же данных SLA.
Сергей Пушняков пишет:
Что имеем: Консультанты периодически забывают переводить в ожидание Запросы и Рабочие Задания, если в течение рабочего дня это не так страшно, хотя тоже не хорошо, это ужасно когда остается на ночь.
Что надо: Придумать схему, при которой можно было бы выключать Запросы и Рабочие Задания по вечерам, если компьютер Консультанта выключен или заблокирован.
А цель сего какая? Избежать просрочки? Для этого, например, есть стандартные механизмы.