Об услугах, хранимых на складе

Ключевое отличие услуги от товара состоит в том, что услуга не может храниться, в книжках по маркетингу даже говорится, что оказание услуги идет одновременно с ее потреблением. В общем случае это верно. Типичный пример стандартной услуги - электроэнергия. Вроде бы вот они провода, включил лампочку - она светит, а счетчик вертится, считает киловатты. Ничего не хранится.
А можно сделать эту услугу накапливаемой? Да, можно. К примеру, услуга по заправке аккумуляторов для электрокаров: привозят разряженные аккумуляторы, а забирают заряженные. Зарядка аккумуляторов совпадает по времени с потреблением услуги? - Нет, потому что момент потребления это когда забирают заряженный аккумулятор. То есть за счет наличия материального носителя - аккумулятора - услуга оказывается хранимой, т.е. приобретает черты товара.
Реально я столкнулся с такой ситуацией по работе у нас на одном из участков мехобработки - туда привозят чужую (давальческую) продукцию для мехобработки или гидроиспытания. Для нас время производства услуги (учитывается по нарядам и вообще является драйвером распределения затрат) и момент возврата клиенту обработанной продукции и выставления акта об оказании услуг - могут вообще быть в разных месяцах. Еще в этой ситуации интересно то, что эти услуги - стандартизированы, их вполне можно учитывать по количеству (в отличие от ремонта электродвигателей - там услуги во многом индивидуальны, сильно зависят от вида поломки).
В общем, при наличии материального носителя (давальческой продукции) услуга обретает черты товара. При этом она не тождественна этому носителю - одна и та же единица продукции может нести несколько услуг: мехобработка, гидроиспытания, УЗК и т.п.

Электронный архив - набросок проектной документации

Есть у нас проблема: куча информации лежит в экселевских таблицах, текстовых документах и т.п. С этими файлами ведется двоякая работа:
а) В один xls-файл несколько пользователей вносят информацию - маленькие кусочки, но ежедневно. В основном это ежедневная сводка для руководства. Работать с файлом по сети - бывает, Excel начинает виснуть. Да и пойди пойми, кто сейчас занял файл.
Примечание: да, знаю, что по уму это не в файле хранить надо, а в базе данных. Возражения тут следующее: руководство очень часто меняет формат этой сводки, нужная информация должна умещаться на одной-двух страницах; так что разумной автоматизации не получается - поди пойми, что в следующий раз понадобится, а что мешать будет.
б) Разные группы пользователей должны иметь разный доступ к документам, в основном быстро найти и открыть на просмотр. Рулить на уровне NTFS неудобно, к тому же если все в файлах, то имена у этих файлов как автор захочет. Неудобно, в общем.
в) Случайная порча файла - случается; быстро восстановить предыдущую копию - а она хорошо если вчерашняя, а надо бы получасовой давности.

Вот чтобы это все как-то разгрести и хочется положить все такие файлы на web-сервер, зарегистрировать их в базе данных и нормально с ними работать - хранить историю версий, работать не по сети, а "скачал - отредактировал - вернул". И чтобы специальный робот смотрел выбранные каталоги на выбранных машинах, и если файлы изменились, добавлял их новые версии в базу данных. В общем, функции электронного архива и системы управления версиями.
Понятно, что таких систем имеется много; но все же напишем свою, больше для того, чтобы разобраться в потребностях, да и с нашим трекером удобней будет состыковывать. Ниже - набросок проектной документации.

1. Общие требования к ЭА

Номинальная емкость системы - 1,000,000 документов, т.е. ID это шестизначное целое число с ведущими нулями. Реальная емкость, исходя из которой рассчитываем сейчас объемы и скорости - 10,000 документов.
Система предназначена для хранения файлов, которые мы считаем бинарными - т.е. без анализа их содержимого. Реально там будут текстовые файлы (форматы txt, doc, odt, pdf, htm и т.п.), файлы электронных таблиц (xls, ods), всевозможные файлы инженерной графики и изображения (в основном отсканированные образы документов).
Быстрая работа системы требуется с текущими версиями документов, добавление нового документа/новой версии, получение одной предыдущей версии документа. Работа с более ранними версиями может быть не быстрой - это гораздо более редкое событие.


2. Хранение файлов в ЭА

Файлы хранятся в папке на сервере, точнее - по подпапкам (не более 100 файлов в папке для ускорения работы с файлом). При помещении в ЭА файл переименовывается - новое имя совпадает с его ID в ЭА с ведущими нулями, расширение остается прежним.
Версии файла нумеруются четырьмя знаками, имя файла версии имеет вид ID_VER, где ID 6 знаков, VER четыре знака. Версии файла, кроме предпоследней, могут храниться как в виде файла на сервере, так и в tar-архиве для экономии места.
Для каждого файла (ID) может быть установлен режим хранения его версий - к примеру, храним одну ежедневную версию (на конец дня), или храним все версии возраста менее недели, потом оставляем из них ежедневные версии, а по истечении месяца - только еженедельные. В заархивированном виде лучше хранить те версии, которые уже предназначены для весного хранения (или можно их разбить по разным архивным файлам).


3. ER-диаграмма ЭА




4. Функции ядра ЭА

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

В каждую функцию передается как один из аргументов Пользователь, от имени которого вызывается функция. Две цели: (1) проверить права, может ли данный пользователь выполнять эту функцию; (2) записать в БД имя пользователя как актора действия (там, где это требуется).

ДобавитьНовыйДокумент(Файл /поток загрузки/)
- возвращает ID файла в ЭА

ВзятьДокумент(ID файла, Режим= просмотр/редактирование)
- возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID
- если файл взят на редактирование, то устанавливает в БД блокировку на него с указанием имени взявшего файл пользователя

ДобавитьВерсиюДокумента(ID файла, Файл /поток загрузки/)
- возвращает номер версии файла (пред. + 1)

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

ПолучитьРеквизитыДокумента(ID файла)
- возвращает список пар "реквизит/значение"

УстановитьРеквизитыДокумента(ID файла, новые реквизиты)
- функция для редактирования всяческих реквизитов файла в БД; новые реквизиты - список пар "реквизит/новое значение"

ПолучитьВерсиюФайлаПоНомеру(ID файла, номер версии)
- возвращает поток скачивания файла. Имя файла - то, что задано как пользовательское в БД, можно в комбинации с ID и номером версии

ПолучитьСписокВерсийФайла(ID файла)
- список троек "номер версии/дата версии/статус (есть ли реально)"


5. Взаимодействие с пользователями и приложениями

В основном с электронным архивом пользователь будет работать не напрямую, а через трекер - практически все документы относятся к какому-нибудь бизнес-процессу, он либо положен в 1С (тогда ID файлов храним там), либо для его автоматизации заводим экземпляр трекера с соответствующей диаграммой состояний, и храним ID файлов в инцидентах.



6. Роботы ЭА

В электронном архиве работают два робота (программы, запускающиеся по времени, раз в сутки).

Робот-архиватор раз в сутки проверяет, не обновились ли указанные в листах-шаблонах файлы (и не появились ли новые), и добавляет новую версию в электронный архив. Требуется в основном для программных файлов на макроязыке 1С (формат txt, ert), места они занимают немного, а когда срочно исправляешь ошибку, можно и забыть сохранить предыдущую версию (особо полезно, когда исправление ошибки привело к возникновению новой - понять, что не так).
Обратное действие к действиям робота - развернуть программные файлы в тех версиях, которые были на определенную дату. Это важно, если мы хотим восстановить старую архивную копию 1С - внутренний программный код сохраняется, а все внешние отчеты и программные модули надо хранить отдельно. Вот для этого робот-архиватор и нужен.

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

------------------------------

Вот примерно такой первый набросок. По ходу дела буду додумывать. Хотя бы систему прав - как удобно сделать.

ER-диаграмма трекера (основные таблицы)

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



В общем, с конца октября трекер у нас работает для управления задачами отдела IT, уже более-менее нормально. Чего не сделано из того, что есть на первой ER-диаграмме:

1. Механизм влияющих инцидентов. Управлять задачами, четко указывая, что "задача1 должна быть сделана раньше задачи2" - почти никогда такого нет; скорее "нельзя начинать делать задачу2, не начав делать задачу1" - почти наверняка эта самая зависимость касается только части задачи1, можно ее начать, сделать только то, что необходимо для задачи2, и сначала завершить задачу2, не завершая задачу1. То есть связь не типа "конец-начало", а более гибкая. Расставив зависимости, мы можем посмотреть, какие задачи надо взять в работу, чтобы можно было выполнить эту, нужную. Пока не сделано.

2. Подчиненные инциденты. Иногда одна задача дробится на несколько: к примеру, в заявке заказчика есть несколько деталей, сначала заявка рассматривается коммерческим директором и директором по производству целиком (они имеют право решить, что она нам не интересна), а потом доходит до отдела главного металлурга, где по деталям раздается нескольким технологам, дальше все движение идет по этим подзадачам. И в самом конце эти подзадачи опять собираются вместе и заказчику высылается протокол согласования цены по его заявке. Вот этот механизм - шла одна задача, потом разделилась, а потом снова собралась - пока не реализован. Идея такая: когда задача разделяется, то старая задача замирает без движения в некотором состоянии, и не может двинуться, пока все ее подчиненные задачи не придут в финальные состояния. При этом финальные состояния могут быть как положительными (технология оценена, есть калькуляция на деталь), так и отрицательными (данную деталь мы не можем произвести). Для этого предназначена ссылка "рамочный инцидент", но основная работа - в реализации логики движения. Пока не сделано.

3. Основной исполнитель. Для задач отдела IT ясно, что основное состояние - "в работе". Исполнитель в этом состоянии - тот, кто на самом деле и выполнил эту задачу. Для движения заявок - ясно, что это технолог (при этом менеджер коммерческого отдела, притащивший эту заявку, уже виден как автор задачи). В общем, ловить этого исполнителя и потом анализировать по нему статистику - полезно, но не слишком критично. Пока не сделано.

4. Прикрепленные файлы. Если к трекеру присобачить еще систему управления версиями (электронный архив), то получится хороший инструмент для автоматизации документооборота. Если все файлы хранятся в едином архиве, то в разных экземплярах трекера для разных бизнес-процессов рисуем свои диаграммы состояний - и вот оно, счастье! Это не только не сделано, это я только проектирую. Скорее всего, следующий пост будет об этом.

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

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

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