Это диаграмма "сущность-связь" нашего трекера. Разумеется, это логическая схема, к тому же на ней нет ничего, связанного с управлением доступом. Трекер пишется с таким расчетом, чтобы можно было под каждый бизнес-процесс заводить свой экземпляр трекера со своей диаграммой состояний. Для управления задачами IT-отдела - один экземпляр, для служебных записок отдела главного металлурга - другой, для заявок от клиентов (та основная задача, ради чего все затевается) - третий. Разумеется, пользователь должен входить в систему один раз и там быть сразу авторизован во всех системах, в которых зарегистрирован. Поэтому мы вынесли систему авторизации вовне.
В общем, с конца октября трекер у нас работает для управления задачами отдела IT, уже более-менее нормально. Чего не сделано из того, что есть на первой ER-диаграмме:
1. Механизм влияющих инцидентов. Управлять задачами, четко указывая, что "задача1 должна быть сделана раньше задачи2" - почти никогда такого нет; скорее "нельзя начинать делать задачу2, не начав делать задачу1" - почти наверняка эта самая зависимость касается только части задачи1, можно ее начать, сделать только то, что необходимо для задачи2, и сначала завершить задачу2, не завершая задачу1. То есть связь не типа "конец-начало", а более гибкая. Расставив зависимости, мы можем посмотреть, какие задачи надо взять в работу, чтобы можно было выполнить эту, нужную. Пока не сделано.
2. Подчиненные инциденты. Иногда одна задача дробится на несколько: к примеру, в заявке заказчика есть несколько деталей, сначала заявка рассматривается коммерческим директором и директором по производству целиком (они имеют право решить, что она нам не интересна), а потом доходит до отдела главного металлурга, где по деталям раздается нескольким технологам, дальше все движение идет по этим подзадачам. И в самом конце эти подзадачи опять собираются вместе и заказчику высылается протокол согласования цены по его заявке. Вот этот механизм - шла одна задача, потом разделилась, а потом снова собралась - пока не реализован. Идея такая: когда задача разделяется, то старая задача замирает без движения в некотором состоянии, и не может двинуться, пока все ее подчиненные задачи не придут в финальные состояния. При этом финальные состояния могут быть как положительными (технология оценена, есть калькуляция на деталь), так и отрицательными (данную деталь мы не можем произвести). Для этого предназначена ссылка "рамочный инцидент", но основная работа - в реализации логики движения. Пока не сделано.
3. Основной исполнитель. Для задач отдела IT ясно, что основное состояние - "в работе". Исполнитель в этом состоянии - тот, кто на самом деле и выполнил эту задачу. Для движения заявок - ясно, что это технолог (при этом менеджер коммерческого отдела, притащивший эту заявку, уже виден как автор задачи). В общем, ловить этого исполнителя и потом анализировать по нему статистику - полезно, но не слишком критично. Пока не сделано.
4. Прикрепленные файлы. Если к трекеру присобачить еще систему управления версиями (электронный архив), то получится хороший инструмент для автоматизации документооборота. Если все файлы хранятся в едином архиве, то в разных экземплярах трекера для разных бизнес-процессов рисуем свои диаграммы состояний - и вот оно, счастье! Это не только не сделано, это я только проектирую. Скорее всего, следующий пост будет об этом.
Комментариев нет:
Отправить комментарий