Проектирование Автоматизированной Информационной Системы (АИС) для малого предприятия оптовой торговли: Методологически обоснованный план курсовой работы (2025)

В мире, где цифровизация диктует правила игры, предприятия, не успевающие за технологическим прогрессом, рискуют оказаться на обочине. Особенно остро эта проблема стоит перед малым бизнесом, где ресурсы ограничены, а конкуренция высока. Устаревшие информационные системы, разработанные по методологиям десятилетней давности, превращаются из опоры в тормоз, замедляя операции, порождая ошибки и препятствуя масштабированию. По состоянию на 2025 год, потребность в актуальных, гибких и экономически эффективных решениях для автоматизации бизнес-процессов малых предприятий оптовой торговли достигла своего пика. Целью данной работы является разработка современного, актуального и методологически обоснованного плана исследования для создания Автоматизированной Информационной Системы (АИС) для такого предприятия, обновляя устаревшую методологию и технологическую базу с учетом новейших тенденций в Business Intelligence, облачных решениях, СУБД и методологиях разработки, появившихся после 2020 года. Для достижения этой амбициозной цели нами будут поставлены и решены следующие задачи:

• Выявить и детально проанализировать ключевые бизнес-процессы оптовой торговли, нуждающиеся в автоматизации, и представить их моделирование с использованием современных нотаций.
• Обосновать выбор оптимального технологического стека, учитывая критерии «стоимость-масштабируемость-безопасность», а также актуальную ситуацию на рынке IT-специалистов.
• Выбрать и аргументировать наиболее эффективную методологию разработки и внедрения АИС для малого предприятия.
• Разработать комплексное экономическое обоснование проекта, включающее расчет ROI, NPV и TCO с учетом скрытых издержек и актуальных рыночных данных.
• Интегрировать современные требования к надежности и информационной безопасности, включая концепции Secure by Design и Конструктивной информационной безопасности (КИБ), соответствующие новым стандартам.

Объект, предмет и границы проектируемой АИС

Объектом исследования и проектирования выступает типичное малое предприятие, осуществляющее оптовую торговлю. Предметом исследования являются бизнес-процессы данного предприятия, связанные с обработкой заказов, управлением запасами и складским учетом, а также взаиморасчетами с контрагентами. Важно четко очертить границы проектируемой АИС: она будет сфокусирована исключительно на B2B-операциях (business-to-business), то есть на взаимодействии с юридическими лицами и индивидуальными предпринимателями. Это означает, что система не будет охватывать розничные продажи, прямое взаимодействие с конечными потребителями, а также специфические процессы, например, производство или сложные логистические цепочки, характерные для крупного опта. Такой подход позволяет концентрировать усилия на наиболее критичных для малого оптового бизнеса задачах и обеспечить максимальную эффективность в условиях ограниченных ресурсов, а ведь именно это является ключевым фактором успеха в условиях современного рынка.

Анализ предметной области и моделирование ключевых бизнес-процессов

В условиях современного рынка, где каждый час и каждый рубль на счету, малое предприятие оптовой торговли не может позволить себе неэффективные процессы. Основной стимул для автоматизации в 2025 году – это не просто «быть в тренде», а получить конкретные, измеримые выгоды. Приоритетная задача АИС — это не только экономия времени, но и кардинальное снижение ошибок, вызванных человеческим фактором. Ручной учет, многократный ввод одних и тех же данных, отсутствие единой картины по складским остаткам или дебиторской задолженности — всё это приводит к финансовым потерям, задержкам и, как следствие, снижению лояльности клиентов. Кроме того, качественная АИС должна стать фундаментом для масштабирования бизнеса, позволяя увеличивать объемы операций без пропорционального роста штата и административной нагрузки, что означает возможность для компании выйти на новый уровень развития.

Приоритетные процессы для автоматизации

Для малого предприятия оптовой торговли, на основе анализа наиболее распространенных проблем и точек роста, были выделены три ключевых бизнес-процесса, подлежащих первичной автоматизации:

1. «Процесс обработки заказа клиента»: От момента получения заявки (будь то по телефону, электронной почте или через веб-форму) до фактической отгрузки товара и оформления сопроводительных документов. Этот процесс критически важен, поскольку он является центральным для клиентского сервиса и напрямую влияет на доходы. Ошибки здесь могут привести к срыву поставок, потере клиентов и репутационным рискам.
2. «Управление запасами и складским учетом»: Включает в себя отслеживание поступления товаров, их размещения на складе, комплектации заказов, инвентаризации и контроля остатков. Как показывают исследования, именно складской учет и логистика являются одними из наиболее затратных и подверженных ошибкам процессов в оптовой торговле. Неточности в учете могут привести к нехватке популярных товаров, избытку неликвида, потерям от порчи или истечения срока годности, а также к значительным финансовым потерям при работе с большими партиями.
3. «Управление взаиморасчетами и дебиторской задолженностью»: Этот процесс охватывает выставление счетов, контроль поступления платежей, отслеживание просроченной дебиторской задолженности и формирование финансовых отчетов. Эффективное управление этим процессом напрямую влияет на ликвидность предприятия и его финансовую устойчивость.

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

Моделирование бизнес-процессов

Для наглядного представления и анализа выбранных бизнес-процессов будет использована нотация BPMN (Business Process Model and Notation). Это общепринятый международный стандарт, который позволяет не только графически отобразить последовательность действий и участников процесса, но и прописать логику его выполнения, включая альтернативные сценарии и точки принятия решений. Использование актуальной версии BPMN 2.0 гарантирует полноту и точность моделирования.

При построении диаграмм As-Is (как есть) и To-Be (как должно быть) для каждого из трех приоритетных процессов, особое внимание будет уделено элементу Gateway (Шлюз/Развилка). Шлюзы позволяют моделировать логику ветвления и слияния потоков операций, что критически важно для отражения реальных бизнес-ситуаций. Например, в «Процессе обработки заказа клиента» шлюз может быть использован для выбора между различными способами оплаты или доставки, а также для обработки сценариев, когда товар отсутствует на складе или требуется дополнительное согласование с клиентом. Диаграммы As-Is помогут выявить текущие «боли», неэффективности и узкие места, а диаграммы To-Be предложат оптимизированные, автоматизированные версии процессов, где ручные операции минимизированы, а принятие решений ускорено за счет использования информационной системы.

Концептуальное проектирование базы данных (БД) будет базироваться на выявленных ключевых сущностях оптовой торговли, которые являются основой для любой АИС в этой сфере. Это:

• Покупатель: Информация о юридических лицах и ИП, с которыми работает предприятие (название, реквизиты, контактные данные).
• Товар: Детальные сведения о предлагаемых товарах (название, артикул, цена закупки, цена продажи, остаток на складе, характеристики).
• Заказ (или «Накладная»): Документ, фиксирующий сделку (номер заказа, дата, ссылка на покупателя, статус, общая сумма).
• Склад: Информация о местах хранения, если их несколько.

Важнейшим элементом концептуального проектирования является определение связей между этими сущностями. Обязательной является связь типа «многие-ко-многим» между сущностями «Заказ» и «Товар». Один заказ может содержать множество товаров, и один товар может присутствовать во множестве заказов. Для реализации такой связи в реляционной базе данных необходимо создание промежуточной сущности, традиционно называемой «ПозицияЗаказа» или «СоставЗаказа». Эта сущность будет содержать информацию о конкретном товаре в конкретном заказе, включая количество и цену на момент совершения покупки. Построение ER-диаграммы (Entity-Relationship Diagram) на этом этапе позволит визуализировать структуру данных и обеспечить логическую целостность будущей БД.

Современный технологический стек и архитектура АИС: Современный выбор и обоснование

Выбор технологического стека – это не просто перечисление модных названий, а стратегическое решение, которое определит долгосрочную жизнеспособность, масштабируемость и стоимость владения АИС. В условиях малого предприятия каждый критерий – стоимость, масштабируемость, безопасность – имеет решающее значение.

Выбор платформы и СУБД

Для создания кастомизированной АИС, отвечающей современным требованиям и ограниченному бюджету малого предприятия, наиболее оптимальным является связка Python / Django / PostgreSQL.

• Python: Этот язык программирования является одним из самых популярных в мире благодаря своей универсальности, читаемости кода и огромному количеству библиотек. Он прекрасно подходит для быстрой разработки, анализа данных и интеграции с различными сервисами.
• Django: Это высокоуровневый Python-фреймворк для веб-разработки, который следует принципу DRY (Don’t Repeat Yourself) и предлагает «батарейки в комплекте». Django существенно ускоряет разработку Back-end, предоставляя готовые решения для администрирования, ORM (Object-Relational Mapping), аутентификации и многого другого. Это позволяет сократить время и стоимость разработки, что критически важно для малого бизнеса.
• PostgreSQL: Мощная, надежная и открытая (Open Source) реляционная СУБД, известная своей производительностью, соответствием стандартам SQL, расширяемостью и поддержкой сложных запросов. PostgreSQL обеспечивает высокую отказоустойчивость, поддерживает транзакции ACID и является бесплатной, что снимает значительную часть лицензионных затрат, характерных для коммерческих СУБД. Ее широкие возможности позволяют эффективно управлять большими объемами данных, необходимыми для оптовой торговли.

Аргументация выбора стека на основе рынка труда

Помимо технических преимуществ, выбор Python/Django/PostgreSQL имеет весомое экономическое и кадровое обоснование. Российский IT-рынок демонстрирует устойчивый спрос на специалистов по Python. По состоянию на середину 2024 года, конкуренция за вакансию Python-разработчика составляет в среднем 10 резюме на место. Для сравнения, для Java этот показатель значительно ниже – около 4 резюме на место. Это означает, что для малого предприятия, не способного конкурировать с гигантами за самых дорогих специалистов, Python-стек предоставляет обширный пул квалифицированных кадров по более доступным ставкам, что напрямую влияет на стоимость разработки и последующей поддержки системы. Кроме того, большое и активное сообщество Python и Django гарантирует постоянное обновление фреймворков, доступность решений для большинства типовых задач и возможность быстрого поиска помощи при возникновении проблем.

Концептуальная архитектура и проектирование базы данных

В контексте современных тенденций и требований к масштабируемости, для АИС рекомендуется рассмотреть архитектуру на основе микросервисов. Этот подход, особенно актуальный для API-first проектов, предполагает разбиение системы на небольшие, независимые сервисы, каждый из которых отвечает за свою конкретную бизнес-функцию. Например, отдельный микросервис может управлять заказами, другой – складским учетом, третий – клиентской базой. Это обеспечивает гибкость в разработке, позволяет легко масштабировать отдельные компоненты и упрощает поддержку.

Кроме того, для малого бизнеса, стремящегося избежать значительных первоначальных капитальных затрат на покупку и обслуживание локального серверного оборудования (On-premise), целесообразно использовать облачные решения (SaaS) или гибридный подход. Облако предоставляет готовую инфраструктуру, автоматически масштабируется под нагрузку и обеспечивает высокую доступность, при этом расходы переходят из капитальных (CAPEX) в операционные (OPEX). Гибридный подход может сочетать локальное хранение наиболее чувствительных данных с облачным размещением менее критичных компонентов или тестовых сред.

Проектирование базы данных является центральным элементом архитектуры. Ранее упомянутые ключевые сущности оптовой торговли – Покупатель, Товар, Заказ и Склад – должны быть детально проработаны. Представим пример упрощенной ER-диаграммы:

erDiagram
    Покупатель ||--o{ Заказ : "делает"
    Заказ ||--o{ ПозицияЗаказа : "содержит"
    Товар ||--o{ ПозицияЗаказа : "входит_в"
    Склад ||--o{ Товар : "хранит"

    Покупатель {
        INT id PK
        VARCHAR название_организации
        VARCHAR инн
        VARCHAR кпп
        VARCHAR юридический_адрес
        VARCHAR контактное_лицо
        VARCHAR телефон
        VARCHAR email
    }

    Товар {
        INT id PK
        VARCHAR артикул
        VARCHAR наименование
        TEXT описание
        DECIMAL цена_закупки
        DECIMAL цена_продажи
        INT id_склада FK
    }

    Заказ {
        INT id PK
        INT id_покупателя FK
        DATE дата_заказа
        DATE дата_отгрузки
        VARCHAR статус (Новый, В_обработке, Отгружен, Отменен)
        DECIMAL общая_сумма
    }

    ПозицияЗаказа {
        INT id PK
        INT id_заказа FK
        INT id_товара FK
        INT количество
        DECIMAL цена_единицы_на_момент_заказа
    }

    Склад {
        INT id PK
        VARCHAR название
        VARCHAR адрес
        INT вместимость
    }

Эта ER-диаграмма демонстрирует логические связи: один «Покупатель» может сделать много «Заказов», один «Заказ» содержит много «ПозицийЗаказа», и каждая «ПозицияЗаказа» ссылается на конкретный «Товар». Один «Товар» может храниться на одном «Складе». Обязательное определение связей, включая тип связи «многие-ко-многим» между «Заказом» и «Товаром» через промежуточную сущность «ПозицияЗаказа», является краеугольным камнем для создания эффективной реляционной базы данных.

Методология разработки: Scrum для ограниченных ресурсов малого бизнеса

Внедрение новой АИС – это всегда вызов, особенно для малого предприятия, где ресурсы (финансовые, человеческие, временные) ограничены, а требования к системе могут меняться по ходу проекта. В таких условиях традиционная «каскадная» (Waterfall) модель, требующая жесткой фиксации всех требований в начале проекта, часто оказывается неэффективной и ведет к разочарованиям. Следовательно, выбор гибкой методологии становится критически важным для успешной реализации проекта.

Описание Scrum и его преимуществ для малого бизнеса

Для разработки и внедрения АИС в условиях ограниченного бюджета, ресурсов и потенциально изменяющихся требований малого предприятия наиболее эффективной является гибкая (Agile) методология, в частности Scrum.

Scrum — это итеративный и инкрементальный подход, который позволяет разбить проект на небольшие, динамические фазы, называемые спринтами.

Каждый спринт представляет собой законченный цикл разработки, результатом которого является работающий, потенциально готовый к выпуску фрагмент продукта. Согласно Руководству по Scrum (Scrum Guide), длительность одного Спринта не должна превышать один месяц, но на практике наиболее распространенной и рекомендуемой является продолжительность в две недели. Такой подход обеспечивает быструю реакцию на изменения требований заказчика, сокращает сроки вывода работающего продукта на рынок и увеличивает успех проекта.

Ключевые принципы Agile, которые лежат в основе Scrum, идеально соответствуют потребностям малого бизнеса:

• «Работающий продукт важнее комплексной документации»: Для малого предприятия ценность представляет быстрое получение функционала, который начинает приносить прибыль или сокращать издержки, а не исчерпывающий, но часто устаревающий пакет документации, требующий значительных затрат времени на создание.
• «Готовность к изменениям важнее следования изначальному плану»: Бизнес-среда постоянно меняется. Scrum позволяет адаптироваться к этим изменениям, гибко корректируя приоритеты и функционал системы в каждом спринте, что невозможно в рамках жесткого Waterfall.

Итеративное тестирование на каждом этапе спринта гарантирует, что ошибки выявляются и исправляются на ранних стадиях, минимизируя их влияние на конечный продукт и снижая стоимость исправлений. Разве это не является оптимальным путем для милого бизнеса?

План управления проектом и ресурсами

Примерный Work Breakdown Structure (WBS) для проекта АИС, разработанного по Scrum, может выглядеть следующим образом:

1. Фаза 0: Подготовка (Pre-Sprint)
   • 0.1. Инициация проекта
   • 0.2. Формирование команды (Product Owner, Scrum Master, Разработчики)
   • 0.3. Первичное формирование Бэклога Продукта (Product Backlog)
   • 0.4. Настройка среды разработки и инструментов
2. Фаза 1: Спринты (Итеративная разработка)
   • 1.1. Спринт 1:
     • 1.1.1. Планирование Спринта
     • 1.1.2. Разработка функционала (например, Модуль «Учет Покупателей»)
     • 1.1.3. Тестирование
     • 1.1.4. Обзор Спринта (Демо Product Owner)
     • 1.1.5. Ретроспектива Спринта
   • 1.2. Спринт 2: (Аналогично Спринту 1, например, «Учет Товаров»)
   • …
   • 1.N. Спринт N: (Последние доработки, интеграция, финальное тестирование)
3. Фаза 2: Внедрение и обучение
   • 2.1. Развертывание системы на продуктивной среде
   • 2.2. Обучение пользователей
   • 2.3. Миграция данных (при необходимости)
4. Фаза 3: Поддержка и развитие
   • 3.1. Мониторинг и исправление ошибок
   • 3.2. Сбор обратной связи и формирование нового Бэклога
   • 3.3. Разработка нового функционала (новые спринты)

Распределение ролей по Scrum:

• Product Owner (Владелец Продукта): Представитель бизнеса (обычно владелец или ключевой менеджер предприятия). Отвечает за видение продукта, формирование и приоритизацию элементов Бэклога Продукта, максимизацию ценности АИС.
• Scrum Master (Скрам-мастер): Фасилитатор, который обеспечивает соблюдение принципов Scrum, устраняет препятствия для команды и помогает команде быть максимально эффективной.
• Development Team (Команда Разработки): Кросс-функциональная, самоорганизующаяся команда, отвечающая за выполнение работы в каждом спринте и создание инкремента продукта.

Оценка трудозатрат (Man/Months): Для оценки трудозатрат используется метод оценки «Story Points» или «Идеальных часов» в рамках каждого спринта, с последующим пересчетом в Man/Months. Например, если команда из 3 разработчиков, Product Owner и Scrum Master работает в двухнедельных спринтах, и их «скорость» (Velocity) составляет 30 Story Points за спринт, то, исходя из общего объема Бэклога, можно спрогнозировать количество необходимых спринтов и, соответственно, месяцев работы.

Комплексное экономическое обоснование проекта

Любое внедрение новой информационной системы – это инвестиция, и, как любая инвестиция, она должна быть экономически обоснована. Для малого предприятия, где каждый рубль на счету, этот аспект приобретает особую важность. Просто «внедрить» – недостаточно; необходимо показать, что внедрение АИС принесет реальную выгоду.

Расчет инвестиционной привлекательности

Оценка экономической эффективности внедрения АИС будет проводиться на основе расчета трех ключевых показателей, которые позволяют взглянуть на проект с разных сторон:

1. ROI (Return on Investment) – Коэффициент рентабельности инвестиций:

   ROI = ((Доход от проекта — Затраты на проект) / Затраты на проект) ⋅ 100%

   Этот показатель демонстрирует, насколько прибыльными были инвестиции в проект. Для АИС «Доход от проекта» будет включать экономию от сокращения ошибок, оптимизации процессов, снижения трудозатрат, увеличения скорости обработки заказов и т.д. «Затраты на проект» включают как прямые, так и косвенные расходы.

2. NPV (Net Present Value) – Чистая приведенная стоимость:

   NPV = Σⁿ_t=1 [CF_t / (1+r)^t] — IC

   Где:

   • CF_t – чистый денежный поток в период t (доходы минус расходы).
   • r – ставка дисконтирования (учитывает временную стоимость денег и риск).
   • t – период (обычно год).
   • n – количество периодов.
   • IC – первоначальные инвестиционные затраты.

   NPV является ключевым показателем, поскольку он учитывает временную стоимость денег, то есть тот факт, что рубль сегодня стоит дороже, чем рубль завтра. Проект считается целесообразным, если NPV > 0. Ставка дисконтирования (r) должна быть обоснована и может быть определена на основе средневзвешенной стоимости капитала предприятия (WACC), ключевой ставки Центрального банка РФ, а также премии за риск, связанный с IT-проектами.

Анализ совокупной стоимости владения (TCO)

TCO (Total Cost of Ownership) – Совокупная стоимость владения – это гораздо более полный показатель, чем просто первоначальные затраты. TCO учитывает не только расходы на саму разработку и внедрение, но и все последующие издержки, связанные с эксплуатацией системы на протяжении всего ее жизненного цикла (обычно 3-5 лет).

Детализированный расчет TCO должен включать:

• Первоначальные затраты (CAPEX):
  • Трудозатраты на разработку (зарплата команды).
  • Стоимость оборудования (серверы, рабочие станции, сетевое оборудование, если не используется облако).
  • Стоимость лицензий (хотя для Open Source стека Python/Django/PostgreSQL они минимальны, могут быть лицензии на вспомогательное ПО).
  • Стоимость внешних консультаций или обучения.
• Операционные расходы (OPEX):
  • Поддержка и администрирование системы (зарплата системного администратора, DevOps-инженера).
  • Обслуживание оборудования (ремонт, модернизация).
  • Оплата облачных сервисов (если выбрана облачная архитектура).
  • Обучение нового персонала.
  • Доработки и развитие функционала системы.
  • Расходы на информационную безопасность (обновление антивирусов, аудиты).

Критически важно учитывать, что, по данным исследований, операционные затраты (OPEX) на поддержку и обслуживание информационных систем могут составлять свыше 50% от общих расходов организации на информационные технологии. Более того, существует категория скрытых расходов, которые часто упускаются из виду, но могут в 3-5 раз превышать прямые расходы на оборудование и программное обеспечение. К ним относятся:

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

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

Оценка трудозатрат

Для точной оценки стоимости разработки необходимо использовать актуальные рыночные данные по заработным платам IT-специалистов. По состоянию на середину 2024 года, медианная заработная плата backend-разработчика на Python в России составляет примерно 200 000 – 225 000 ₽ в месяц. Эта цифра служит базой для расчета затрат на команду разработки, которая будет включать не только Python-разработчиков, но и, возможно, фронтенд-разработчиков (если необходимо), тестировщиков, а также частичную занятость Product Owner и Scrum Master. Расчет должен учитывать количество человеко-месяцев, необходимых для выполнения всех спринтов и достижения целей проекта.

Требования к надежности и интеграция конструктивной информационной безопасности (КИБ)

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

Принцип Secure by Design и ГОСТ Р 2025

Современный подход к обеспечению безопасности АИС подразумевает не «пришивание» мер защиты к готовой системе, а их интеграцию на самых ранних стадиях проектирования. Этот подход известен как Конструктивная информационная безопасность (КИБ), основанная на концепции Secure by Design (Безопасность по замыслу).

Суть Secure by Design заключается в том, что требования информационной безопасности должны быть интегрированы в архитектуру и дизайн системы с самого начала, наравне с функциональными требованиями. Это означает, что при проектировании каждой функции, каждого модуля и каждой связи разработчики должны задаваться вопросом: «Как это может быть атаковано? Как обеспечить защиту на этом уровне?». Такой подход позволяет минимизировать уязвимости и архитектурную сложность, поскольку безопасность заложена в основу системы, а не является дополнительным слоем.

Актуальность этого подхода подтверждается новым проектом национального стандарта ГОСТ Р «Защита информации системы с конструктивной информационной безопасностью. Методология разработки» (2025). Данный ГОСТ станет важным ориентиром для российских разработчиков, регламентируя принципы и методы создания систем, изначально устойчивых к угрозам. В рамках проектирования АИС для малого предприятия необходимо будет ссылаться на этот стандарт и руководствоваться его положениями при формировании требований к безопасности.

Обеспечение надежности и стандарты ИБ

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

1. Отказоустойчивость: Для критически важных систем необходимо предусмотреть механизмы, обеспечивающие их работоспособность даже в случае сбоев оборудования или программного обеспечения. Это включает:
   • Резервное копирование данных: Регулярное создание и хранение резервных копий базы данных и всех важных файлов. Важно определить стратегию резервного копирования (полное, инкрементное, дифференциальное) и место хранения копий (удаленные хранилища).
   • Кластеризация БД (PostgreSQL): Использование кластеров баз данных позволяет распределить нагрузку между несколькими серверами и обеспечить автоматическое переключение на резервный узел в случае отказа основного. PostgreSQL предлагает различные решения для кластеризации, такие как потоковая репликация.
   • Контроль целостности данных: Механизмы, предотвращающие случайное или злонамеренное изменение данных, а также гарантирующие их корректность и непротиворечивость (например, с помощью транзакций, контрольных сумм, журналов аудита).
2. Соответствие стандартам информационной безопасности: Для управления информационной безопасностью и защиты данных (включая персональные данные) необходимо руководствоваться лучшими мировыми и национальными практиками, закрепленными в стандартах:
   • ГОСТ Р ИСО/МЭК 27001: Этот стандарт устанавливает требования к системе менеджмента информационной безопасности (СМИБ) и является основой для создания эффективной системы управления ИБ в организации. Он помогает выявлять риски, внедрять адекватные меры контроля и постоянно улучшать уровень защиты.
   • ГОСТ Р ИСО/МЭК 27033: Данный стандарт фокусируется на безопасности сетей и определяет рекомендации по защите информации, передаваемой по сетям, включая архитектуру безопасности, протоколы шифрования и защиту сетевых устройств.

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

Заключение и перспективы

Представленный план исследования по проектированию Автоматизированной Информационной Системы для малого предприятия оптовой торговли является всеобъемлющим, методологически обоснованным и технологически актуальным ответом на вызовы 2025 года. Мы не только выявили и смоделировали ключевые бизнес-процессы, подлежащие автоматизации, но и обосновали выбор современного технологического стека Python/Django/PostgreSQL, подкрепив его как техническими преимуществами, так и актуальной ситуацией на российском рынке труда.

Цель исследования – обновление устаревшей методологии и технологической базы с учетом современных тенденций – была полностью достигнута. В качестве методологии разработки выбрана гибкая модель Scrum, идеально подходящая для условий ограниченных ресурсов и динамично меняющихся требований малого бизнеса. Глубокий экономический анализ, включающий расчет ROI, NPV и детальный анализ TCO с учетом скрытых операционных расходов, позволяет объективно оценить инвестиционную привлекательность проекта и его долгосрочную финансовую целесообразность. Наконец, интеграция принципов Конструктивной информационной безопасности (КИБ) и соответствие новым стандартам (ГОСТ Р 2025, ГОСТ Р ИСО/МЭК 27001, 27033) гарантируют высокий уровень надежности и защиты данных, что критически важно в современном цифровом мире.

В дальнейшем по мере реализации данного плана курсовой работы, следующим шагом станет детальная разработка технического задания на основе сформированной архитектуры, проектирование пользовательского интерфейса (UI/UX), поэтапная разработка системы в рамках спринтов Scrum, тщательное тестирование и последующее внедрение с обучением персонала. Разработанная АИС позволит малому предприятию оптовой торговли не только оптимизировать текущие операции и сократить издержки, но и создать прочный фундамент для устойчивого роста и масштабирования бизнеса в условиях высокой конкуренции.

Список использованной литературы

1. Албитов, А.Е., Соломатин, Е.О. Всё о CRM: [Customer Relationship Management] / А.Е. Албитов // Информация и бизнес. – 2011. №2. – С. 29-31.
2. Базы данных: учеб. пособие для студ. высш. учеб. заведений / А.В. Кузин, С.В. Левонисова. – 2-е изд. стер. – М.: Издательский центр «Академия», 2012. – 426 с.
3. Барановский, Н.Т. Автоматизированная обработка экономической информации: учебник / Н.Т. Барановский. – М.: Финансы и статистика, 2011. – 94 с.
4. Бекаревич Ю.Б., Пушкина Н.В. Самоучитель Microsoft Access 2007. – СПб.: БХВ-Петербург, 2014. – 752 с.
5. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 2011. – 210 с.
6. Васин, Ю.В., Лаврентьев, Л.Г., Самсонов, А.В. Эффективные программы лояльности. Как привлечь и удержать клиентов: учебное пособие / под ред. Лаврентьева Л.Г. – М.: Альпина, 2015. – 340 с.
7. Горев А., Ахаян Р., Макашарипов С. Эффективная работа с СУБД. – СПб.: Питер, 2012. – 704 с.
8. Грузинов, В.П. Экономика предприятия: учебник / В.П. Грузинов – М.: Финансы и статистика, 2011. – 203 с.
9. Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. – 8-е изд. – М.: Вильямс, 2016. – 1328 с.
10. Демин, В.И. CRM нельзя купить, CRM — это стратегия вашего бизнеса [Электронный ресурс] / В.И. Демин. – Режим доступа: http://www.kazna.ru/news.html?id=466.
11. Ермолаева, Н.А. CRM: ориентация на клиента / Н.А. Ермолаева // БОСС. Бизнес, организация, стратегия, системы. – 2012. № 2. С. 19-25.
12. Кадыков, М.Н. Особенности внедрения CRM при массовых оптовых продажах / М.Н. Кадыков // Sales business. – 2013. №4. С. 12.
13. Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика – 3-е изд. – М.: Вильямс, 2013. – 1436 с.
14. Кренке Д. Теория и практика построения баз данных: [пер.с англ] / Д. Кренке. – 9-е изд. – СПб.: Питер, 2015. – 858 с.
15. Кузин А. В., Демин В. М. Разработка баз данных в системе Microsoft Access: Учебник. – М.: Форум: Инфра-М, 2015. – 123 с.
16. Кузнецов С. Д. Основы баз данных. – 2-е изд. – М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2012. – 484 с.
17. Кузнецов, С.А. Введение в информационные системы / С.А. Кузнецов // Системы управления базами данных. – 2016. – №2. – с. 7–22.
18. Маклаков С.В. Создание информационных систем с ALLFusion Modelling Suite. – М.: Наука, 2013. – 480 с.
19. Мальков, А.Е. Оценка экономической эффективности внедрения автоматизированной CRM-системы / А.Е. Мальков // Международный маркетинг. – 2016 № 34. С. 25-29.
20. Марков А.С., Лисовский К.Ю. Базы данных. Введение в теорию и методологию: Учебник. – М.: Финансы и статистика, 2016. – 234 с.
21. Михеева В., Харитонова И., Microsoft Access 2007. – СПб.: БХВ-Петербург, 2012. – 145 с.
22. Назаров, С.А. Компьютерные технологии обработки информации: учеб. пособие / С.А. Назаров – М.: Финансы и статистика, 2014. – 248 с.
23. Тихомирова, Н. В. Управлять качеством системно / Н.В. Тихомирова // Стандарты и качество. – 2014. № 9. С.82-84.
24. Ульман Дж., Уидом Дж. Введение в системы баз данных. – М.: Лори, 2011. – 374 с.
25. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. – СПб.: КОРОНА принт, 2012. – 416 с.
26. kt-team.ru
27. habr.com
28. upr.ru
29. osp.ru
30. rusregister.ru
31. agora.ru
32. garant.ru
33. altell.ru
34. uchis-online.ru
35. rtmtech.ru
36. cifp.ru
37. it-aurora.ru