Внутренняя система учёта расходных материалов — всё вместе¶

Эта страница собирается из компактных разделов проектной документации. Отдельные файлы разделов остаются источником истины; эта страница предназначена для последовательного чтения, ревью и экспорта в стиле PDF.

Содержание¶

Краткое описание
Обзор
Контекст и проблема
Цели, требования и ограничения
Роль и обязанности
Модель системы
Архитектура и интеграции
Безопасность, качество и эксплуатация
Решения, компромиссы и риски
Дорожная карта и демонстрация
Architecture Decision Records

Краткое описание¶

Статус¶

partial implementation / historical project

Роль¶

инициатор, автор концепции, разработчик прототипа

Стек¶

Тип: Internal automation / early ERP-like inventory system; Период: ранний этап перехода от администрирования инфраструктурой к разработке внутренних систем

Ценность проекта¶

Лёгкая внутренняя ERP-подобная система для учёта расходных материалов ИТ-отдела - остатки, история движения и планирование закупок.

Обзор¶

Краткое описание¶

Создать лёгкую внутреннюю ERP-систему для отдела ИТ: не как большой корпоративной платформы, а как прикладного инструмента, который помогает видеть текущие остатки, историю движения материалов и будущую потребность в закупках.

Технологический стек¶

Spring Boot backend
Thymeleaf простой UI
Локальный запуск

Контекст и проблема¶

Контекст¶

Проект возник из практической операционной боли ИТ-отдела: расходные материалы закупались, выдавались, списывались и планировались вручную или в разрозненных таблицах. Основной объект учёта - картриджи для принтеров и другие ИТ-расходники, связанные с регулярными закупками, остатками, выдачей, заменой и прогнозированием потребности.

Идея заключалась в создании лёгкой внутренней ERP-системы для отдела ИТ: не как большой корпоративной платформы, а как прикладного инструмента, который помогает видеть текущие остатки, историю движения материалов и будущую потребность в закупках.

Проблема¶

До появления такой инициативы учёт расходников был зависим от ручной дисциплины, локальных файлов и памяти сотрудников. Это создавало типовые проблемы:

сложно быстро понять актуальные остатки;
трудно восстановить историю поступления и выдачи;
закупки планировались реактивно, а не на основе накопленных данных;
не было единой структуры справочников и операций;
данные были полезны для отдела, но плохо формализованы как система.

Цели, требования и ограничения¶

Цели и нецели¶

Создать внутренний инструмент для учёта расходных материалов, который позволял бы отслеживать остатки, фиксировать движение и поддерживать планирование закупок вместо ручного учёта в таблицах.

Требования¶

Система должна была позволять:

вести справочник расходников;
фиксировать поступления;
учитывать выдачу и списание;
видеть текущие остатки;
анализировать динамику потребления;
поддерживать планирование закупок;
снизить зависимость от ручного учёта и разрозненных таблиц.

Частично реализованный объём¶

Концепция внутренней системы учёта расходников.
Базовая структура справочников и операций.
Подход к фиксации поступлений и расхода.
Табличная модель для практического учёта.
Использование накопленных данных для планирования закупок.
Переход от хаотичного ручного учёта к более структурированной модели.

Ограничения¶

Роль и обязанности¶

Проект был начат как самостоятельная разработка с нуля, но не оформлен, как законченная ERP-система. Однако проект важен не как завершённый production-продукт, а как ранняя точка перехода от роли системного администратора к роли человека, который проектирует и создаёт прикладные ИТ-системы.

Модель системы¶

Доменная модель¶

В основе решения лежала простая, но прикладная доменная модель:

расходный материал;
тип расходника;
модель оборудования;
совместимость расходника и оборудования;
складской остаток;
поступление;
выдача;
списание;
подразделение или место использования;
история движения;
плановая потребность;
закупочная заявка или закупочная потребность.

Модель данных¶

Диаграмма классов¶

classDiagram
    class ConsumableItem {
      id
      name
      sku
      type_id
    }

    class ConsumableType {
      id
      name
    }

    class EquipmentModel {
      id
      vendor
      model
    }

    class StockMovement {
      id
      type
      quantity
      date
      item_id
      consumer_id
      comment
    }

    class Department {
      id
      name
    }

    class Place {
      id
      name
      department_id
    }

    class ConsumerEquipment {
      id
      name
      place_id
      model_id
    }

    ConsumableItem --> ConsumableType
    ConsumableType --> EquipmentModel
    StockMovement --> ConsumableItem
    StockMovement --> ConsumerEquipment
    ConsumerEquipment --> Place
    Place --> Department

API-контракты¶

Архитектура и интеграции¶

Архитектура¶

Архитектурный подход¶

Проект задумывался как многослойный модульный монолит: прикладная логика, модель данных, простой пользовательский интерфейс и слой хранения должны были быть разделены по ответственности, но без преждевременного усложнения архитектуры.

Потоки интеграции¶

Безопасность, качество и эксплуатация¶

Модель безопасности и доступа¶

Нефункциональные требования¶

Режимы отказа¶

Оценка масштаба и стоимости¶

Решения, компромиссы и риски¶

Ключевые решения¶

Компромиссы¶

Модульный монолит без преждевременного усложнения¶

Прикладная логика, модель данных, простой пользовательский интерфейс и слой хранения разделены по ответственности - без распределённой архитектуры и преждевременной абстракции для внутреннего прототипа.

Ранний прототип vs завершённая ERP¶

На текущем уровне зрелости проекта корректнее рассматривать его как early internal automation prototype, а не как завершённую ERP-систему.

См. также Architecture Decision Records.

Дорожная карта и демонстрация¶

Дорожная карта¶

Скриншоты и демо¶

Что демонстрирует проект¶

ExpendIt показывает мой ранний переход от инфраструктурной роли к разработке внутренних систем и системному анализу.

В этом проекте уже появились элементы, которые позже стали частью моего профессионального профиля:

разбор реальной операционной боли;
выделение сущностей предметной области;
попытка построить модель учёта;
стремление заменить ручной процесс структурированной системой;
практическая автоматизация для внутреннего пользователя;
внимание к данным, истории операций и планированию.

Проект не был завершён как зрелый продукт, но стал важным шагом в сторону системного мышления, разработки и последующего перехода в системный анализ.

Architecture Decision Records¶

См. Architecture Decision Records.