LogEnterprise — это централизованный программный комплекс, позволяющий централизованно хранить и оперативно обмениваться информацией о состоянии подготовки документации, производства и сборки деревянных конструкций. Основными задачами системы на предприятии являются:
1. Хранение проектной документации в структурированном легко доступном через веб-интерфейс виде.
2. Сбор и предоставление в удобном виде исчерпывающей информации о состоянии производства каждого проекта от уровня общей статистики до уровня отдельных деталей.
3. Передача информации о ходе работы над проектом от одного участка работ к другому через центральную базу данных.
4. Обеспечение прозрачности производственного процесса для руководства предприятия и заказчика.
Система предоставляет «multi-tenant environment», то есть с одной базой данных могут независимо работать множество предприятий, не мешая друг другу.

Что привносит этот проект в структуру нашего программного пакета? Это ДВЕ ВЕЩИ:
1. Централизованное хранение информации. Сейчас всё использование пакета предполагает постоянный обмен файликами между разными частями предприятия. Файлики не имеют версий, их распространение не контролируется, ими обмениваются когда как: на флешках, по почте, через шары и т.п.. Новая система должна это исключить. Вместо этого все проекты, над которыми работает предприятие, должны быть жёстко структурированы, все файлы должны храниться в одном месте — на сервере, — а доступ к ним можно было бы регулировать. И все документы доступны отовсюду через веб-интерфейс.

Что такое документы:
- файлы PDF
- файлы Word
- файлы Excel
- файлы LogHouse

Дело в том, что по каждому проекту не должно быть просто КУЧИ ФАЙЛОВ. Должен быть конкретный список документов. Это наши Типы документов.

Когда мы смотрим на проект, мы должны понять:
- какие документы у него ДОЛЖНЫ быть?
- какие документы УЖЕ ЗАГРУЖЕНЫ?
- кто и когда загрузил каждый документ?
Это основные вопросы, с ответов на которые надо начать. Дальше пока что не надо автоматизировать. Из этого следует, что на странице проекта должна быть таблица Документы, где показаны ВСЕ типы документов и каждая строка начинается либо с иконки зелёной галочки (есть) или с красного крестика (его ещё нет). Щёлкнув на строку любого документа мы попадаем на страницу КОНКРЕТНОГО ТИПА ДОКУМЕНТА для КОНКРЕТНОГО ПРОЕКТА. Что мы ту должны увидеть:
- есть документ или его ещё не прикрепили к этому проекту? Из этого следует, что в верхней части большими буквами написано имя загруженного файла, если он есть.
- загрузка документа этого типа для этого проекта. Это обозначает, что должна быть большая область для удобной загрузки документа через drag-and-drop + поле для выбора пути с кнопкой «Загрузить». Можно начать только с поля с кнопкой :)
- мы уже говорили, что документ можно ОБНОВИТЬ. в смысле интерфейса это обозначает, что если мы загружаем документ в тип, где уже был документ, последний становится УСТАРЕВШЕЙ ВЕРСИЕЙ, а новый АКТУАЛЬНОЙ ВЕРСИЕЙ. Из этого следует, что ниже на этой странице есть таблица «История», где указаны имена файлов, даты-время загрузки и пользователи, которые грузили прежние версии. Имя является ссылкой, по которой эту старую версию можно скачать.

Пока это всё по документам.

Что мы знаем о проекте ещё? В первой версии LogEnterprise проект почти не имеет собственных полей. Он является только «контейнером» для документов и состояния производства. Из важных полей:
- Название — у всех проектов есть имя собственное
- Заказчик — строковое поле для указания заказчика, о котором мы больше ничего знать пока не хотим
- Описание — текстовое поле для ввода свободного текста, который мы не знаем как будет применять
- Фотогалерея — набор картинок, которые этот проект представляют. Сюда могут загрузить что-то красивое, если проект будет виден клиентам, или узнаваемое, если проект будет виден сотрудникам.
- общие параметры сруба — это будет группа полей, значения которых мы достанем из файла LogHouse.
По сути это самое важное. Больше полей я опишу в структуре БД.

Таким образом, отвечая на вопрос «что такое проекты» — это средство структурировать работу предприятия.
Один проект = 1 дом. По одному проекту может быть собрано несколько экземпляров домов.
Наша задача — собрать под Проектом всю Проектную Документацию, достаточную чтобы дом произвести и собрать.
Вся информация лежит в документах, поэтому в базе данных мы храним про проект минимум информации.

2. Централизованное хранение информации о состоянии производства. Сейчас информация о состоянии производства хранится только на станке. И только если наша программа интегрирована со станком. Это очень редкий случай, и на большинстве предприятий информация о состоянии производства недоступна ВООБЩЕ. Мы должны изменить эту ситуацию.

Что такое производство. Мы делаем софт для заводов, которые делают СТЕНОВЫЕ ЭЛЕМЕНТЫ рубленных домов. Так называется то, с чем имеет дело программа LogHouse, LogFactory, LogConstruct и т.п. — Стеновые Элементы. Давайте договоримся, что в этом проекте мы ПОНИМАЕМ, что дом состоит из РАЗНЫХ деталей, но на этом ПЕРВОМ этапе развития проекта мы ограничиваемся работой только со Стеновыми Элементами. Именно поэтому таблица для хранения деталей называется parts (т.е. просто «детали») — это на вырост. Сейчас в ней мы будем размещать только один уже знакомый вам по LogConstruct тип деталей.

Итак, в рамках нашего проекта, Производство — это процесс изготовления Стеновых Элементов сруба из заготовок. И далее Сборка этого сруба.

Таким образом, «состояние производства» — это:
- список всех стеновых элементов проекта
- для каждого элемента стадия его изготовления и установки

Откуда берётся информация о Стеновых Элементах в базе данных:
Если ВСЕ документы мы рассматриваем просто как файлы, которые надо просто хранить и учитывать, то файлы LogHouse мы будем РАЗБИРАТЬ ДО ДЕТАЛЕЙ. То есть у нас будет специальный Тип Документа — «Разбревновка». К этому типу можно загрузить только файл с расширением LGH, который будет полностью интерпретироваться и раскладываться по базе данных.

Какая ещё информация добавляется:
На каждый Стеновой Элемент «наматывается» информация о том, как он появляется — вот мы определили, что мы будем изговаливать его из заготовки такого-то размера, вот мы его уже изготовили, вот мы его упаковали на палету, вот мы отправили палету с завода на стройплощадку, вот мы его установили на стену. Это всё НОВАЯ информация, ради накопления которой мы и делаем LogEnterprise. Когда мы говорим «показать состояние производства» — это обозначает, что мы для КАЖДОЙ ДЕТАЛИ показываем, что с ней УЖЕ произошло и КОГДА. Это подводит нас к третьей задаче LogEnterprise.

3. Централизованное хранение информации о процессе производства.
Что есть процесс в нашем случае: это информация о том, КОГДА было произведено то или иное действие.
Мы можем сколько угодно смотреть на то, в каком СОСТОЯНИИ находятся наши проекты: тут сделано 34% деталей, тут уже установлено 55% деталей, этот проект полностью собран и сдан. Но это даст нам только ЧАСТЬ информации. В рамках LogEnterprise мы хотим научиться накапливать и начать анализировать характеристики ВРЕМЕНИ производства.

В идеале мы должны ответить на вопросы такого типа:
- какая смена обрабатывает больше кубометров древесины за смену: утренняя или вечерняя?
- сколько времени в среднем уходит на доставку упакованных деталей на стройку?
- когда мы работали быстрее: в июне или в сентябре?
- сколько в среднем времени проходит от разбревновки до завершения производства?

Как мы этого достигнем:
ОЧЕНЬ ПРОСТО. У нас есть таблица event_log. В ней должны записываться ВСЕ СОБЫТИЯ, которые происходят на производстве. Чуть только что-то произошло — мы фиксируем это событие: загружен документ, изготовлена деталь, установлена деталь и т.п.. Потом мы можем запросами в базе данных отвечать на все интересующие нас вопросы. В таблице может быть намного больше ссылок на объекты, чем я нарисовал на доске. Если мы фиксируем события связанные с документом — значит в таблицу event_log надо добавить document_id и так далее.

Этот подход даёт так же возможность для РАССЛЕДОВАНИЯ происшествий. Например, поставку дома затянули. По таблице event_log мы легко поднимаем все события, связанные с данным Производством. И сразу видим, кто и когда послужил причиной задержки.

В рамках нашего с вами этапа мы собираемся сделать каркас для накопления этих данных, зафиксировать основные типы событий и сделать несколько простейших отчётов. Как вы, наверное, понимаете, анализ данных о Процессе Производства является бесконечной задачей, и в наш проект мы включим только самые основные функции:
- сводный отчёт по производительности труда. Это будет один отчёт с таблицами и графиками, показывающий разброс показателей по времени выполнения операций.
- показ Истории объекта для расследования. Это будет просто страница с таблицей, в которую выводится выборка из event_log. Переход на эту страницу возможен с большинства страниц, показывающих какой-либо объект: проект, документ, деталь. На всех подобных страницах должна появиться легко узнаваемая кнопка «История».