Диаграмма состояний трекера отдела IT

Для управления задачами отдела IT решили использовать такую диаграмму состояний:



При создании новая задача (инцидент) находится в виртуальном стартовом состоянии № 0 и должна быть переведена в какое-то нормальное состояние. Диаграмма по сути распадается на две - программистские задачи и прочие задачи. Нас в основном интересуют программистские задачи, но и прочие тоже важны - провести сеть в цех, к примеру, или выполнить тестирование базы 1С. Пусть для них будут свои состояния, но чтобы мы могли учитывать все задачи.
Программистские задачи. Бледно-желтые состояния это состояния ожидания, накопители. В них у задачи не может быть исполнителя. Руководитель проекта (разделение по проектам мы потом реализуем с помощью тегов) выдает задачи в работу конкретным исполнителям, задача переходит в активное состояние (ярко-зеленое). Нормальный путь - сделанная программистом задача передается на тестирование. Если все нормально, то с тестирования она переходит в финальное состояние "Выполнено". Финальные состояния различаются двух видов: положительные исходы (темно-зеленые) и отрицательные исходы (бордовые). Финальное состояние не имеет исполнителя и не может иметь исходящих стрелок.
На диаграмме изображены все возможные переходы между состояниями задачи (инцидента). К примеру, с тестирования задача может быть возвращена на доработку - сама диаграмма показывает, что признать задачу выполненной может только тот, кто проводил тестирование, не программист (теоретически; на практике эти роли могут совмещаться в одном человеке, но только потому, что нас мало). Жирной стрелкой показан переход, который предлагается по умолчанию. Т.е. из каждого нефинального состояния должна исходить ровно одна жирная стрелка.
В трекере не предусмотрено удаление задач; все переходы регистрируются в истории инцидента с указанием пользователя, который совершил это действие. Для единообразия смена исполнителя реализована как переход с совпадающими начальным и конечным состояниями. Добавление примечания регистрируется тоже как переход.

Исполнителей (программистов, тестеров) должны интересовать активные состояния (ярко-зеленые), а руководитель проекта в основном занят управлением инцидентами в пассивных состояниях - что передать в работу и когда это сделать. Отдельный вопрос - состояние № 9 "Help me!". Оно используется, если программист столкнулся с концептуальной проблемой, решение которой влияет на архитектуру системы. Тут важно, чтобы исполнитель распознал, что проблема не его уровня; выделение же таких проблем в отдельное состояние гарантирует, что руководитель проекта вовремя узнает о них.

Вот, вкратце, описание трекера. Он реализован в web-интерфейсе, работает в Опере и Мозилле.

Трекер - общая идея

Решили тут написать свой трекер в web-интерфейсе. С чего это вдруг:
1. Есть куча задач, которые можно решить на одной методологической основе - через управление инцидентами с использованием диаграмм состояний. Эти задачи (не все):
- задачи отдела IT (как создание нового функционала, так и поддержка существующего
- маркетинговая подготовка производства (управление заявками клиентов)
- управление ремонтами и доработкой модельной оснастки - фактически документооборот служебных записок ОГМет и цеха.
В общем, там, где приминимо понятие инцидента - спорадически возникающего объекта (события), разбираться с которым необходимо индивидуально (т.е. даже схожие не суммируются и не объединяются в группы/партии), к тому же маршрут инцидента не определен однозначно (возможны движения между разными исполнителыми, в том числе по циклу). Хочется иметь инструмент управления инцидентами, который можно настраивать для разных задач.
2. Но вроде бы много есть таких инструментов? При внимательном анализе - нет; в различных багтрекерах система состояний в основном прошита в архитектуре и не является настраиваемой (легко настраиваемой). Впрочем, есть и системы с настраиваемой диаграммой состояний - TrackStudio, к примеру, куда более навороченная, чем то, что мы в состоянии написать. По уму надо было бы на чем-то таком делать. Но тут мне самому интересно спроектировать такую систему, да и по ходу продумать требования к ней. Лучше бизнес-процессы выращивать, чем пересаживать - для второго нужно куда больше опыта. Так что напишем свой трекер (уже задачи отдела IT ведем в нем), а уж следующие проекты можно будет делать в чем-нибудь более мощном - как методология станет более знакомой и понятной.

Впрочем, надо быть честным до конца - в том, что трекер пишем сами, есть немалый элемент случайности. Год назад, когда эта идея подошла к реальному воплощению, я хотел покрутить TrackStudio, но времени не было. А мой программист, который должен был работать на этом проекте, как раз писал диплом. Трекер как тема вполне годился, но нужно было чтобы было программирование. Короче, решили совместить приятное с полезным (или неприятное с бесполезным - позже поймем, что это было) и написать свой трекер. Диплом он успешно защитил на пятерку и вот теперь решили попробовать это в деле - пока для управления своими задачами, сначала под себя отстроим, потом уже и другие бизнес-процессы на его основе автоматизируем.

Формализация задачи планирования 2

В продолжение вчерашней записи.
Если чуть изменить задачу, то можно обойтись двукратным решением задачи линейного программирования (или это ее частный случай - транспортная задача? не помню).

Меняем задачу так: Проверить выполнимость плана. Если не выполним, то скомплектовать плавки, максимизируя общую массу отлитого; если план выполним, то добавляем к нему план следующей недели и комплектуем плавки так, чтобы был полностью выполнен план текущей недели и еще отлито что-то из следующего плана, по-прежнему максимизируем массу отлитого.

Т.е. исходим из того, что оборудование должно быть загружено максимально. Для нашего завода это разумная посылка - заказов много и проблема их выполнить все в срок. Еще тут предполагается, что мы планируем критичное оборудование, т.е. узкое место именно здесь, увеличение производительности здесь не создаст проблем на остальных участках. В общем, голдраттовская "теория ограничений" на практике.

Формальная постановка задачи и алгоритм чуть меняются:
1. Проверка выполнимости плана:
(Сумма по j) X_ij <= A_i - текущий план как ограничение
(Сумма по i) M_i*X_ij < C_j - верхнее ограничение массы плавки (нижнее аналогично)
Целевая функция: (Сумма по i и j) M_i*X_ij -> max - максимизируем общую массу отлитого.

2. Опорное решение элементарно: все X_ij=0

3. Решаем транспортную задачу, получаем оптимальное решение.

4. Если план выполним, то первая группа ограничений реализуется как равенство: (Сумма по j) X_ij = A_i
Если это не соблюдено, то план невыполним и полученное решение это тот максимум, который мы можем сделать из плана текущей недели.

5. Если план выполним, то увеличиваем систему: добавляем в нее план следующей недели, но отдельными позициями (т.е. "отливка А" из плана текущей недели и "отливка А" из плана следующей недели - это две разные позиции, хотя физически они одинаковые).

6. Ограничения для плана текущей и плана следующей недели различаются: для текущей недели берем равенства, для следующей недели - неравенства. Целевая функция такая же (с учетом того, что переменных в ней больше).

7. Решение, полученное на предыдущем этапе, является опорным для новой задачи (новые переменные мы приравниваем 0).

8. Решаем транспортную задачу с практически удвоенным числом переменных и находим оптимальную комплектацию плавок.

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

Формализация задачи планирования

Сейчас начал автоматизировать создание сменных заданий в сталелитейном цехе. Задача комплектации плавок. Неформально она описывается так:
Имеется недельный план - сколько каких отливок надо отлить, каждая отливка имеет расчетный вес и марку стали. В печи плавится сталь (сколько-то тонн) и надо скомплектовать плавки. Цель - выпустить все и при этом за минимальное количество плавок.
Аналогичная задача на цветном и электрошлаковом литье, но там вопрос не в плавках, а в термообработке - комплектация садки. Там задача минимизации числа садок вообще в чистом виде - расход энергии от массы садки не зависит, все определяется режимом термообработки.
Вот вчера понял, как формализовать задачу, описать ее математически:

1. Рассматриваем марки стали отдельно - редкие случаи, когда излишек выплавленной "хорошей" стали заливаем вместо "обычной", не рассматриваем. То есть рассмотрим задачу для одной марки стали.

2. План состоит из n наименований отливок, для i-й отливки масса одной шт. M_i, количество по плану A_i

3. Пусть у нас есть несколько печей и масса плавки имеет две границы - нижнюю и верхнюю (для термообработки нижнюю границу можем считать 0). Для каждой печи мы знаем максимальное количество плавок, которое можно сделать за неделю (т.е. планируемый период). Дальше отвлечемся от печей и рассматриваем плавки - то, что хотим скомплектовать. Верхнее ограничение массы j-й плавки = C_j (зависит от печи - сначала по первой печи все возможные плавки, потом по второй и т.д.)

4. Пусть X_ij это количество деталей i в плавке j. Тогда можем записать нужные нам уравнения:
(Сумма по j) X_ij = A_i - условие выполнения плана
(Сумма по i) M_i*X_ij < C_j - верхнее ограничение массы плавки (нижнее аналогично)

5. Цель - решить эту систему в неотрицательных целых числах. Оптимальная цель - минимизировать при этом количество плавок.

6. Т.е. алгоритм такой: проверяем, совместна ли исходная система и имеет ли она решение в неотрицательных целых числах. Решение, кстати, и будет комплектацией плавок, т.е. потом остается только раскидать плавки по дням и сменам, и voila!

7. Но перед этим надо оптимизировать решение, т.е. если система совместна, то выкидываем одну плавку и смотрим, имеет ли она решение теперь - если да, то оно лучше первого. Конечно, тут проблема, какую плавку выкинуть - C_j ведь разные. Но они определяются типом печи, которых у нас всего три, так что подойдет простой перебор. Или узнать в цеху их соображения - равномерность загрузки печей? Наоборот, неравномерность - чтобы не прогревать лишний раз печь (первая плавка в день требует больше энергии)?

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

Кстати, если план заведомо невыполним, то этот алгоритм не работает; тогда задача меняется: скомплектовать плавки так, чтобы выпустить максимум продукции по весу. Классическая задача линейного программирования :-)

Поехали!

Меня зовут Тимур Василенко, живу в Пензе, работаю на заводе "МашСталь" директором по IT. Завод металлургический, выпускает черное и цветное литье под заказ, а я занимаюсь автоматизацией этого производства - от бухгалтерии до маркетинговой подготовки производства. Этот блог и посвящен моей работе - что делаю, как делаю, идеи и т.п.

Скажу сразу - бухгалтерия и производственное планирование/диспетчирование у нас сделаны на 1С:7.7. Причины такого выбора:
1. Исторические - сначала фирма занималась только металлоломом, там все было автоматизировано на 1С. Потом с появлением литейных цехов постепенно система наращивалась и дописывалась - эволюционировала, в общем;
2. Специфические - металлургическое производство весьма специфично, так что стандартных решений (типа MRP II для машиностроительного производства) нет или они стоят столько, что заводу на те же деньги можно купить новую производственную линию. С другой стороны, эта специфика не связана с большой сложностью, так что слабые вычислительные возможности 1С вполне достаточны для возникающих задач;
3. Персональные - имеющийся персонал знает 1С, так что хоть со стороны освоенности инструмента нет проблем.
В общем, на чем-то другом можно было бы сделать и круче, но 1С для этой задачи достаточно, и будет достаточно еще несколько лет.

На первых порах буду писать о двух проектах:

Создание документации на базе Wiki-движка. Автоматизировано уже много бизнес-процессов, часть из них достаточно редкие (но сложные). Пользователи забывают - вот решил сделать документацию. Пишу, обдумываю.
Маркетинговая подготовка производства. Это весь тот этап, который от заявки клиента "не могли бы вы изготовить мне вот такую штуку?" до заключения договора на изготовление этой самой штуки. Это не функционал CRM, тут не отношения с клиентом важны, а процедура оценки заявки (сможем ли изготовить и сколько это будет стоить), коммерческий отдел тут по краям процесса, основное - технологи и производство. Систем управления этим процессом я не встречал, так что буду изобретать свое. Концептуально обдумал, практически начнем воплощать через три недели.

Ну и еще одна тема - алгоритмы производственного планирования в привязке к нашему производству.