Разработка автоматизированной информационной системы учета товаров компании: методологическое руководство для дипломной работы

В условиях стремительной цифровизации мировой экономики, когда каждая секунда промедления или неточности может стоить компании значительных финансовых потерь и репутационных рисков, автоматизация бизнес-процессов становится не просто конкурентным преимуществом, а жизненной необходимостью. По данным аналитических агентств, предприятия, внедрившие автоматизированные системы управления, демонстрируют повышение операционной эффективности в среднем на 20-30% уже в первый год эксплуатации. Для компании ООО «Оригами», как и для многих других, точный и оперативный учет товаров является краеугольным камнем успешной деятельности, определяющим прозрачность цепочек поставок, оптимизацию складских запасов и, в конечном итоге, удовлетворенность клиентов.

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

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

Задачи работы:

1. Систематизировать теоретические основы АИС и их жизненного цикла, опираясь на актуальные международные и национальные стандарты.
2. Проанализировать и обосновать выбор методологий проектирования и моделирования для АИС учета товаров, включая структурный и объектно-ориентированный подходы, а также нотации UML и BPMN.
3. Специфицировать функциональные, нефункциональные и эргономические требования к разрабатываемой системе.
4. Разработать принципы проектирования базы данных, включая нормализацию и построение ER-моделей, адаптированных под специфику учета товаров.
5. Провести сравнительный анализ и обосновать выбор оптимальных технологических решений (СУБД, языки программирования) для реализации АИС.
6. Разработать методику оценки экономической эффективности внедрения АИС, включая количественные и качественные показатели.
7. Обосновать меры обеспечения информационной безопасности и соответствие АИС действующей нормативно-правовой базе Российской Федерации.

Объект исследования: Процессы учета товаров в компании ООО «Оригами».

Предмет исследования: Автоматизированная информационная система учета товаров, ее проектирование, разработка и внедрение.

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

Теоретические основы и жизненный цикл автоматизированных информационных систем

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

Понятие и классификация автоматизированных информационных систем

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

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

Эффективность АИС в современном бизнесе:

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

• Увеличение скорости принятия решений: Автоматизация сбора и анализа данных позволяет руководству оперативно получать актуальную информацию о состоянии дел, что критически важно в динамичной рыночной среде.
• Сокращение производственных простоев: Точный учет запасов и планирование поставок минимизируют риски дефицита или избытка товаров, предотвращая сбои в производственных и логистических цепочках.
• Уменьшение количества бизнес-ошибок: Системы с встроенными механизмами валидации данных значительно снижают вероятность ошибок, связанных с ручным вводом или обработкой информации.
• Повышение производительности труда: Освобождение сотрудников от рутинных задач позволяет им сосредоточиться на более сложных, творческих и стратегически важных видах деятельности.
• Улучшение качества продукции и услуг: Более точный контроль над всеми этапами учета и движения товаров способствует повышению общего качества предложения компании.
• Сокращение административно-управленческих расходов: Оптимизация процессов и сокращение трудозатрат на рутинные операции напрямую влияют на снижение накладных расходов.

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

Модели жизненного цикла разработки АИС и их стандартизация

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

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

Стандартизация жизненного цикла АИС:

Чтобы обеспечить единообразие, качество и взаимопонимание между участниками процесса разработки, были разработаны международные и национальные стандарты, регламентирующие процессы ЖЦ ПО и систем.

• Международный стандарт ISO/IEC 12207:1995 (и его российская версия ГОСТ Р ИСО/МЭК 12207-99) стал краеугольным камнем в области стандартизации ЖЦ программных средств. Он определяет стратегию и общий порядок создания и эксплуатации ПО, охватывая весь спектр процессов: от приобретения системы, разработки, поставки, эксплуатации до сопровождения программных продуктов. Стандарт выделяет три группы процессов:
  • Основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение.
  • Вспомогательные процессы: документация, управление конфигурацией, обеспечение качества, верификация, аттестация, совместная оценка, аудит, разрешение проблем.
  • Организационные процессы: управление, создание инфраструктуры, усовершенствование, обучение.

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

• СТБ ISO/IEC/IEEE 12207-2023 представляет собой обновленную версию международного стандарта, которая устанавливает общую основу для процессов жизненного цикла программного обеспечения с четко определенной терминологией. Он включает процессы, действия и задачи, применимые на всех стадиях — от приобретения и поставки до утилизации продуктов.
• ГОСТ Р 57193-2016 (разработан с учетом ISO/IEC/IEEE 15288:2015) расширяет рамки стандартизации, распространяясь на полный жизненный цикл системы в целом, а не только программного обеспечения. Это включает замысел, разработку, производство, эксплуатацию и снятие с эксплуатации, а также приобретение и поставку систем. Важно отметить, что этот ГОСТ не предписывает конкретную модель ЖЦ, но устанавливает требования к процессам, что дает гибкость в выборе подходящей методологии.

Стадии и этапы проектирования АС согласно ГОСТ 34.601-90:

В отечественной практике стандартизации создания автоматизированных систем особое место занимает ГОСТ 34.601-90, который детализирует стадии и этапы проектирования АС. Этот стандарт предоставляет четкую структуру для реализации проекта АИС:

1. Формирование требований к АС: Исходная точка любого проекта, включающая обследование объекта автоматизации, выявление потребностей пользователей и бизнес-процессов, а также разработку технико-экономического обоснования.
2. Разработка концепции АС: На этом этапе определяются основные принципы построения системы, варианты реализации и выбор оптимального решения.
3. Техническое задание (ТЗ): Центральный документ, который фиксирует все требования к системе, ее функции, состав, сроки и порядок разработки. ТЗ является основным документом для взаимодействия между заказчиком и разработчиком.
4. Эскизный проект: Создание предварительных проектных решений, описывающих общую архитектуру системы, ее основные компоненты и интерфейсы.
5. Технический проект: Детальная проработка всех технических решений, включая проектирование базы данных, структуры модулей, алгоритмов, пользовательского интерфейса.
6. Разработка рабочей документации: Подготовка всей необходимой документации для реализации, тестирования, внедрения и эксплуатации системы (руководства пользователя, администратора, программиста).
7. Ввод в действие АС: Включает монтаж, пусконаладочные работы, опытную эксплуатацию, обучение персонала и официальный ввод системы в промышленную эксплуатацию.
8. Сопровождение АС: Поддержка работоспособности системы, устранение ошибок, обновление и развитие функционала в течение всего срока ее службы.

Таким образом, стандартизация ЖЦ ПО не просто упорядочивает процесс, но и обеспечивает его качество, предсказуемость и соответствие лучшим практикам, что критически важно для успешного создания АИС учета товаров для ООО «Оригами», не так ли?

Методологии проектирования и моделирования АИС учета товаров

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

Структурный подход к проектированию АИС

Структурный подход, уходящий корнями в зарекомендовавшие себя инженерные практики, базируется на идее декомпозиции — разложении сложной системы на более мелкие, управляемые компоненты. Его суть заключается в том, что информационная система рассматривается как совокупность функций, которые последовательно делятся на подсистемы, подфункции и задачи, вплоть до конкретных процедур. Этот подход опирается на несколько фундаментальных принципов:

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

В рамках структурного подхода одним из наиболее влиятельных инструментов является методология функционального моделирования SADT (Structured Analysis and Design Technique), разработанная Дугласом Россом и ставшая основной частью программы ICAM (Integrated Computer Aided Manufacturing). Более известная как IDEF0, эта нотация представляет собой совокупность методов, правил и процедур для построения функциональной модели объекта предметной области.

Ключевые особенности IDEF0:

• Функциональная декомпозиция: Система представляется в виде блоков (активностей), каждый из которых выполняет определенную функцию. Эти блоки могут быть декомпозированы на более низкие уровни, раскрывая детализацию процесса.
• Четыре типа стрелок: Взаимодействие между блоками (функциями) описывается стрелками, обозначающими:
  • Входы (Inputs): Данные или объекты, которые преобразуются функцией.
  • Управление (Controls): Условия или правила, регулирующие выполнение функции.
  • Выходы (Outputs): Результаты выполнения функции.
  • Механизмы (Mechanisms): Ресурсы (люди, оборудование, программное обеспечение), которые выполняют функцию.
• Графическая наглядность: IDEF0 позволяет создать легко читаемую иерархическую модель, которая наглядно демонстрирует структуру системы и потоки информации, что облегчает коммуникацию между бизнес-аналитиками, разработчиками и заказчиками.

Применение IDEF0 для АИС учета товаров ООО «Оригами» позволит построить четкую функциональную модель, где будут определены такие функции, как «Приемка товара», «Хранение товара», «Формирование заказа», «Отгрузка товара», а также их взаимосвязи, входы (например, накладные, заявки), выходы (отчеты, списания) и механизмы (сотрудники склада, программное обеспечение АИС). Это создаст прочную основу для дальнейшего проектирования.

Объектно-ориентированный подход и унифицированный язык моделирования UML

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

Основные принципы ООП:

• Абстрагирование: Выделение наиболее существенных характеристик объекта, игнорируя незначительные детали. Например, для «Товара» важны название, артикул, количество, цена, но не цвет упаковки.
• Инкапсуляция: Объединение данных и методов, которые работают с этими данными, в единый объект и сокрытие внутренней реализации от внешнего мира. Это обеспечивает защиту данных и модульность.
• Модульность: Разделение системы на независимые, легко заменяемые компоненты (модули), каждый из которых имеет четко определенные интерфейсы.
• Иерархия: Организация объектов в иерархические структуры через наследование, позволяющая создавать новые объекты на основе существующих, повторно используя их свойства и поведение.

Для объектно-ориентированного моделирования проблемной области широкое распространение получил Унифицированный язык моделирования UML (Unified Modeling Language). Разработанный группой OMG (Object Management Group), UML фактически стал стандартом в области объектно-ориентированных технологий и предоставляет богатый набор графических диаграмм для визуализации, спецификации, конструирования и документирования систем.

Ключевые UML-диаграммы для АИС учета товаров:

1. Диаграмма прецедентов использования (Use-case diagram): Описывает функциональные требования к системе с точки зрения внешних пользователей (акторов). Для АИС учета товаров могут быть такие прецеденты, как «Учет поступления товара», «Оформление отгрузки», «Инвентаризация склада», «Просмотр отчетов по остаткам».
2. Диаграмма классов объектов (Class diagram): Представляет статическую структуру системы, показывая классы (например, «Товар», «Поставщик», «Заказ», «Склад»), их атрибуты (свойства) и методы (операции), а также связи между ними (ассоциации, агрегации, композиции).
3. Диаграмма состояний (Statechart diagram): Моделирует жизненный цикл одного объекта, показывая его возможные состояния и переходы между ними, вызванные событиями. Например, для «Товара» состояния могут быть «На складе», «Зарезервирован», «Отгружен», «Списан».
4. Диаграммы взаимодействия объектов (Interaction diagrams): Включают:
   • Диаграмма последовательности (Sequence diagram): Показывает последовательность сообщений, которыми обмениваются объекты для выполнения определенной задачи или прецедента.
   • Диаграмма кооперации (Collaboration diagram): Фокусируется на связях между объектами, участвующими во взаимодействии.
5. Диаграмма деятельностей (Activity diagram): Отображает потоки управления и данных в рамках одного процесса или операции, аналогично блок-схемам. Может использоваться для моделирования бизнес-процессов внутри системы.

Использование UML-диаграмм позволит команде ООО «Оригами» не только четко структурировать логику АИС учета товаров, но и обеспечить наглядное представление всех ее компонентов и их взаимодействий, что существенно облегчит разработку и дальнейшее сопровождение.

Моделирование бизнес-процессов: BPMN и другие нотации

Проектирование информационной системы неразрывно связано с пониманием и моделированием бизнес-процессов, которые она призвана автоматизировать. Именно здесь на помощь приходят специализированные нотации, позволяющие формализовать, анализировать и оптимизировать последовательность действий в компании.

Исторически существовали различные подходы к моделированию, такие как:

• IDEF0: Как уже было сказано, это функциональное моделирование, акцентирующее внимание на функциях и их взаимодействиях.
• EPC (Event-driven Process Chain): Цепочка процессов, управляемая событиями. Фокусируется на событиях, которые запускают функции, и функциях, которые генерируют события. Широко используется в методологии SAP.

Однако в последние годы доминирующей стала нотация BPMN (Business Process Model and Notation). Она не просто описывает процессы, а создает мост между бизнес-анализом и ИТ-реализацией, что делает ее идеальным инструментом для проектирования АИС учета товаров.

Почему BPMN так популярен?

1. Понятность: BPMN разработан таким образом, чтобы быть понятным как бизнес-аналитикам, так и техническим специалистам. Стандартные символы и правила позволяют однозначно интерпретировать любую модель.
2. Выразительность: Нотация предоставляет богатый набор элементов для описания практически любого бизнес-процесса, включая параллельные ветви, условные переходы, события, сообщения и так далее.
3. Исполняемость: Модели BPMN могут быть не только описательными, но и исполнимыми, то есть напрямую трансформироваться в код или конфигурации BPM-систем.
4. Интеграция с ИТ: BPMN изначально ориентирована на поддержку автоматизации процессов, что позволяет легко переводить бизнес-требования в технические спецификации.

Основные элементы BPMN:

• Объекты потока (Flow Objects):
  • События (Events): Начальные, промежуточные, конечные. Могут быть вызваны таймерами, сообщениями, ошибками и т.д.
  • Действия/Задачи (Activities/Tasks): Единичные шаги процесса, выполняемые человеком или системой.
  • Шлюзы (Gateways): Определяют логику ветвления или слияния потоков (например, эксклюзивные, параллельные, инклюзивные).
• Соединяющие объекты (Connecting Objects):
  • Потоки последовательности (Sequence Flows): Указывают порядок выполнения действий.
  • Потоки сообщений (Message Flows): Описывают обмен сообщениями между различными пулами/участниками.
  • Ассоциации (Associations): Связывают текст или артефакты с объектами потока.
• Пулы и дорожки (Pools and Lanes):
  • Пул (Pool): Представляет собой отдельного участника процесса (например, «Компания ООО «Оригами»», «Поставщик»).
  • Дорожка (Lane): Подразделение внутри пула, обозначающее конкретную роль или отдел (например, «Отдел закупок», «Склад», «Менеджер»).
• Артефакты (Artifacts): Дополнительная информация, не влияющая на логику выполнения, но делающая модель более понятной (например, «Объект данных», «Группа», «Текстовая аннотация»).

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

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

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

Функциональные требования к АИС учета товаров

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

1. Бизнес-требования: Описывают цели компании, для которой разрабатывается продукт. Они фиксируют ценность, которую программа должна приносить бизнесу. Например, для ООО «Оригами» это может быть «сокращение времени на обработку заказа на 15%» или «уменьшение ошибок при отгрузке на 50%».
2. Пользовательские требования: Определяют, какие задачи программа помогает выполнять пользователям, описывают сценарии взаимодействия, роли и уровни доступа. Это взгляд на систему глазами конечного пользователя.

Для АИС учета товаров ООО «Оригами» можно выделить следующие основные функциональные требования:

• Учет поступления товаров:
  • Регистрация новых товаров с указанием наименования, артикула, производителя, категории, единицы измерения, цены закупки.
  • Приемка партии товаров на склад с фиксацией даты поступления, поставщика, номера накладной, количества и стоимости.
  • Автоматическая генерация уникальных идентификаторов для каждой единицы или партии товара (например, штрих-кодов, QR-кодов).
• Управление складскими запасами:
  • Отображение текущих остатков товаров по складам, местам хранения.
  • Функционал инвентаризации (частичной, полной) с возможностью автоматического сравнения фактических и учетных данных и формирования актов расхождений.
  • Поддержка различных единиц измерения и конвертации.
  • Учет сроков годности товаров и оповещение о приближении истечения срока.
  • Регистрация перемещений товаров между складами или ячейками хранения.
• Управление заказами и отгрузками:
  • Формирование заказов от клиентов с указанием позиций, количества, цен.
  • Резервирование товаров под заказ.
  • Создание документов на отгрузку (накладных, актов) на основе заказов.
  • Отслеживание статусов заказов (новый, в работе, отгружен, выполнен).
  • Интеграция с системами логистики для отслеживания доставки.
• Ценообразование:
  • Управление закупочными и розничными ценами, скидками, наценками.
  • Возможность автоматического пересчета цен при изменении закупочной стоимости.
• Отчетность и аналитика:
  • Формирование отчетов по остаткам, оборачиваемости, истории движения товаров.
  • Анализ продаж, прибыли, неликвидов.
  • Экспорт данных в различные форматы (Excel, PDF).
• Управление доступом:
  • Разграничение прав доступа к функционалу системы в зависимости от роли пользователя (администратор, менеджер склада, оператор).
  • Журналирование всех действий пользователей в системе.

Это лишь базовый набор ФТ, который будет уточняться в ходе детального анализа бизнес-процессов ООО «Оригами».

Нефункциональные требования: производительность, надежность, масштабируемость

Если функциональные требования описывают что система делает, то нефункциональные требования (НФТ) определяют как она это делает. Они касаются стандартов и качеств, которым система должна соответствовать для эффективной работы, и фокусируются на внутренних и внешних условиях ее функционирования. Система, созданная без учета НФТ, может выполнять свои задачи, но вопрос в том, насколько качественно, что напрямую влияет на позитивный пользовательский опыт и, как следствие, на востребованность продукта.

Для АИС учета товаров ООО «Оригами» критически важны следующие нефункциональные требования:

1. Производительность:
   • Скорость реакции: Время отклика системы на действия пользователя (например, поиск товара, сохранение накладной) не должно превышать 1-3 секунды для 90% операций при одновременной работе 50 пользователей.
   • Пропускная способность: Система должна обрабатывать не менее 1000 транзакций в час (например, операций по приему/отгрузке) без существенного снижения производительности.
   • Объем данных: Способность эффективно работать с базой данных, содержащей сотни тысяч записей о товарах и миллионы транзакций.
2. Надежность:
   • Доступность: Система должна быть доступна 99.5% времени (т.е. время простоя не более 43 часов в год) в рабочие часы.
   • Устойчивость к сбоям: Наличие механизмов резервного копирования и восстановления данных, минимальное время восстановления после сбоя.
   • Целостность данных: Гарантия сохранения данных без потерь или искажений при любых операциях и сбоях.
3. Масштабируемость:
   • Горизонтальная/Вертикальная: Возможность увеличения производительности путем добавления новых серверов (горизонтальная) или увеличения мощности существующих (вертикальная) для поддержки роста объемов данных и количества пользователей до 500 человек в течение 5 лет.
   • Расширяемость функционала: Архитектура системы должна предусматривать возможность добавления новых модулей (например, интеграция с CRM, системой лояльности) без полной переработки существующей логики.
4. Безопасность:
   • Аутентификация и авторизация: Строгое разграничение прав доступа на основе ролей, надежные механизмы аутентификации пользователей.
   • Защита данных: Шифрование конфиденциальных данных (например, персональных данных клиентов, коммерческой тайны), защита от несанкционированного доступа.
   • Журналирование: Ведение подробных логов всех операций и попыток доступа для аудита и выявления инцидентов.
5. Совместимость:
   • Интеграция: Возможность интеграции с существующими системами (например, бухгалтерским ПО 1С, складским оборудованием) через API.
   • Кроссплатформенность: Если требуется, поддержка работы на различных операционных системах или устройствах (веб-версия, мобильное приложение).
6. Удобство сопровождения:
   • Документированность: Наличие полной и актуальной технической документации.
   • Модульность: Четкое разделение системы на независимые модули для упрощения отладки и модификации.
   • Обучаемость: Легкость освоения системы новыми сотрудниками.

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

Эргономические требования к пользовательскому интерфейсу

Хотя эргономические требования напрямую не всегда выделяются в отдельных ГОСТах, они являются критически важной частью нефункциональных требований, определяющих удобство использования и пользовательский опыт (User Experience, UX). Система, даже самая функциональная и надежная, не будет эффективной, если ее тяжело использовать, если она вызывает у пользователей раздражение или приводит к ошибкам из-за неудобного интерфейса.

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

1. Интуитивность и простота использования:
   • Единый стиль интерфейса: Все элементы управления, меню, кнопки должны быть выполнены в едином стиле и следовать общим принципам дизайна.
   • Логичность навигации: Пользователь должен легко понимать, где он находится в системе и как перейти к нужной функции. Минимальное количество кликов для выполнения частых операций.
   • Визуальная иерархия: Важная информация и элементы управления должны быть выделены, менее важные — менее заметны.
2. Эффективность работы:
   • Минимизация ввода данных: Использование выпадающих списков, автозаполнения, сканирования штрих-кодов для сокращения ручного ввода.
   • Поддержка горячих клавиш: Для ускорения работы опытных пользователей.
   • Четкая обратная связь: Система должна оперативно реагировать на действия пользователя, подтверждая успешное выполнение или указывая на ошибки.
   • Быстрый поиск и фильтрация: Мощные инструменты для быстрого нахождения нужной информации о товарах, заказах, поставщиках.
3. Предотвращение ошибок:
   • Валидация ввода: Автоматическая проверка корректности введенных данных (например, числовые значения в полях количества, даты).
   • Подтверждение критических операций: Запрос подтверждения перед удалением данных или выполнением необратимых действий.
   • Подсказки и справка: Наличие контекстной помощи и доступа к подробной документации.
4. Адаптивность и доступность:
   • Настраиваемость: Возможность настройки интерфейса под индивидуальные предпочтения пользователя (например, расположение панелей, видимость столбцов в таблицах).
   • Цветовая схема: Выбор цветовой палитры, которая не вызывает утомления глаз при длительной работе.
   • Адаптация к различным устройствам: Если предполагается использование системы на планшетах или мобильных устройствах, интерфейс должен быть адаптирован под них.

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

Проектирование базы данных для АИС учета товаров

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

Нормализация реляционных баз данных

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

Основные цели нормализации:

1. Устранение избыточности данных: Самая частая проблема, когд�� одна и та же информация хранится в нескольких местах. Избыточность ведет к увеличению объема БД, замедлению операций и, что самое главное, к потенциальной несогласованности данных.
2. Уменьшение размера базы данных: Устранение избыточности напрямую влияет на компактность хранения данных.
3. Сохранение целостности данных при их изменении: При изменении данных в одном месте нет необходимости обновлять их во множестве других. Это минимизирует риски ошибок и гарантирует актуальность информации.
4. Повышение гибкости и управляемости: Нормализованная структура позволяет легко добавлять новые сущности или изменять существующие без значительных переработок.
5. Минимизация вероятности потери или искажения информации: Благодаря четкой структуре и связям, данные становятся более устойчивыми к сбоям и некорректным операциям.

Основные нормальные формы (НФ):

• Первая нормальная форма (1НФ): Это базовое требование, без которого таблица не считается реляционной. Для соответствия 1НФ необходимо, чтобы:
  • Таблица не содержала повторяющиеся группы (т.е. в каждой ячейке должно быть только одно значение).
  • Все столбцы содержали атомарные (неделимые) значения. Например, поле «Адрес» должно быть разбито на «Улица», «Дом», «Город».
  • Каждая строка была уникальна и идентифицировалась первичным ключом.
  • Пример для учета товаров: В таблице «Товары» не должно быть поля «Поставщики», где через запятую перечислены несколько поставщиков. Вместо этого должна быть отдельная таблица «Поставщики» и связующая таблица «Товары_Поставщики».
• Вторая нормальная форма (2НФ): Таблица находится во 2НФ, если она уже находится в 1НФ, и все неключевые атрибуты полностью зависят от всего первичного ключа. Если первичный ключ составной, то ни один неключевой атрибут не должен зависеть только от части первичного ключа.
  • Пример для учета товаров: Если первичный ключ в таблице «ПозицииЗаказа» состоит из «IDЗаказа» и «IDТовара», а поле «НазваниеТовара» зависит только от «IDТовара», то «НазваниеТовара» следует вынести в отдельную таблицу «Товары».
• Третья нормальная форма (3НФ): Считается самым высоким уровнем нормализации, необходимым для большинства приложений, и требует исключения полей, которые не зависят от ключа. Таблица находится в 3НФ, если она находится во 2НФ, и все неключевые атрибуты не имеют транзитивной зависимости от первичного ключа (т.е. не зависят от других неключевых атрибутов).
  • Пример для учета товаров: Если в таблице «Товары» есть поле «НазваниеПоставщика», и это поле зависит от «IDПоставщика» (который сам является неключевым атрибутом в таблице «Товары», но ссылается на первичный ключ в таблице «Поставщики»), то «НазваниеПоставщика» следует удалить из таблицы «Товары» и получать его через связь с таблицей «Поставщики».

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

Моделирование данных с использованием ER-диаграмм

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

ER-диаграммы строят на этапе концептуального и логического проектирования базы данных. Их основное назначение — помочь разработчикам и бизнес-аналитикам понять структуру данных предметной области и правильно спроектировать таблицы и их взаимосвязи.

Ключевые элементы ER-диаграммы:

1. Сущность (Entity): Представляет собой реальный или абстрактный объект, о котором необходимо хранить информацию. Каждая сущность в ER-диаграмме в конечном итоге становится таблицей в базе данных. В контексте АИС учета товаров это могут быть:
   • Товар
   • Поставщик
   • Клиент
   • Заказ
   • Склад
   • Сотрудник
   • КатегорияТовара
2. Атрибут (Attribute): Характеристика или свойство сущности. Каждый атрибут становится колонкой соответствующей таблицы.
   • Для сущности Товар: ID_Товара, Наименование, Артикул, Цена, КоличествоНаСкладе, СрокГодности.
   • Для сущности Поставщик: ID_Поставщика, Название, Телефон, Адрес.
3. Связь (Relationship): Описывает взаимодействие между двумя или более сущностями. Типы связей определяются кардинальностью:
   • Один к одному (1:1): Например, Товар имеет Один ОписаниеДеталей (которое хранится в отдельной таблице для больших текстовых полей).
   • Один ко многим (1:M): Например, Поставщик поставляет Много Товаров. КатегорияТовара содержит Много Товаров.
   • Многие ко многим (M:N): Например, Заказ может содержать Много Товаров, и Товар может входить во Много Заказов. Такая связь обычно разрешается созданием промежуточной таблицы (например, ПозицииЗаказа).

Процесс построения ER-модели:

1. Получение списка сущностей предметной области: Идентифицировать все значимые объекты, о которых система должна хранить информацию.
2. Определение атрибутов для каждой сущности: Перечислить все важные характеристики каждой сущности.
3. Описание взаимосвязей между сущностями: Установить, как сущности взаимодействуют друг с другом, и определить кардинальность каждой связи.

Пример фрагмента ER-диаграммы для АИС учета товаров:

Сущность Товар	Связь состоит в	Сущность КатегорияТовара
ID_Товара (PK)	(1:M)	ID_Категории (PK)
Наименование		Название
Артикул
Цена
ID_Категории (FK)

Сущность Заказ	Связь содержит	Сущность ПозицииЗаказа	Связь включает	Сущность Товар
ID_Заказа (PK)	(1:M)	ID_Позиции (PK)	(M:1)	ID_Товара (PK)
ДатаЗаказа		ID_Заказа (FK)		Наименование
ID_Клиента (FK)		ID_Товара (FK)		Цена
		Количество

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

Выбор технологических решений для реализации АИС учета товаров

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

Критерии выбора системы управления базами данных (СУБД)

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

При выборе СУБД для АИС учета товаров ООО «Оригами» необходимо руководствоваться следующими ключевыми критериями:

1. Моделирование данных:
   • Поддержка реляционной модели данных (что является стандартом для учетных систем).
   • Наличие инструментов для визуального проектирования схемы БД.
2. Особенности архитектуры и функциональные возможности:
   • Клиент-серверная архитектура: Для обеспечения многопользовательского доступа и централизованного хранения данных.
   • Поддержка транзакций (ACID): Гарантия атомарности, согласованности, изолированности и долговечности операций с данными, что критически важно для финансовых и учетных систем.
   • Язык запросов: Поддержка стандартного SQL.
   • Встроенные функции: Наличие функций для агрегации данных, аналитики, работы со строками и датами.
   • Хранимые процедуры и триггеры: Для реализации бизнес-логики на уровне БД и обеспечения целостности данных.
3. Контроль работы системы:
   • Средства администрирования: Удобные инструменты для мониторинга производительности, резервного копирования, восстановления, управления пользователями и их правами.
   • Журналирование: Детальное логирование всех операций и событий для аудита и отладки.
4. Особенности разработки приложений:
   • Поддержка различных языков программирования: Наличие драйверов и API для популярных языков (C#, Java, Python, PHP и т.д.).
   • Интеграция со средами разработки (IDE): Удобство работы для программистов.
   • Проблемно-ориентированные инструментальные средства: Наличие специфических инструментов для упрощения разработки учетных систем.
5. Производительность:
   • Скорость выполнения запросов: Способность обрабатывать сложные запросы к большим объемам данных за приемлемое время.
   • Оптимизация запросов: Наличие встроенных механизмов оптимизации запросов и индексирования.
   • Поддержка параллельной обработки: Эффективная работа с большим количеством одновременных пользователей.
6. Надежность и доступность:
   • Механизмы резервного копирования и восстановления: Гибкие и автоматизированные средства для обеспечения сохранности данных.
   • Кластеризация и репликация: Возможность построения отказоустойчивых решений (например, для обеспечения непрерывности бизнеса в случае сбоя сервера).
   • Защита данных: Механизмы шифрования, контроля доступа на уровне БД.
7. Требования к рабочей среде:
   • Операционная система: Поддержка используемых ОС (Windows Server, Linux).
   • Аппаратные требования: Сопоставимость с имеющимся или планируемым оборудованием.
8. Смешанные критерии:
   • Стоимость владения (TCO): Включает не только стоимость лицензий, но и затраты на оборудование, разработку, обучение персонала, поддержку и сопровождение.
   • Удобство пользовательского интерфейса: Относится к средствам администрирования СУБД.
   • Квалификация персонала: Наличие на рынке труда специалистов по выбранной СУБД или возможность обучения существующих сотрудников.
   • Поддержка вендора и сообщества: Наличие актуальной документации, регулярных обновлений и активного сообщества пользователей.
   • Масштабируемость в будущем: Способность СУБД расти вместе с потребностями предприятия.

Тщательный анализ этих критериев поможет ООО «Оригами» выбрать СУБД, которая будет не только соответствовать текущим требованиям, но и станет надежной основой для долгосрочного развития АИС учета товаров.

Сравнительный анализ популярных СУБД (Access, SQL Server, Oracle)

Для выбора оптимальной СУБД для АИС учета товаров ООО «Оригами» рассмотрим и сравним три популярные системы: Microsoft Access, Microsoft SQL Server и Oracle Database, каждая из которых имеет свои сильные и слабые стороны.

Microsoft Access

Плюсы:

• Простота использования и низкий порог входа: Идеально подходит для небольших проектов, не требующих глубоких знаний в администрировании БД.
• Низкая стоимость: Часто входит в состав пакета Microsoft Office, что делает ее экономически привлекательной для малых предприятий.
• Визуальные инструменты: Удобные средства для создания форм, отчетов и запросов.
• Интеграция с Microsoft Office: Легко взаимодействует с Excel, Word, Outlook.

Минусы:

• Ограничения по размеру: Общий размер файла базы данных (ACCDB или MDB) ограничен 2 ГБ, за вычетом места, необходимого для системных объектов. Хотя это ограничение можно обойти путем связывания таблиц из других баз данных Access (каждая по 2 ГБ), это создает дополнительные сложности. Для веб-приложений Access в Microsoft 365 и SharePoint Online максимальный размер хранилища БД приложения составляет 1 ГБ. Эти ограничения делают Access непригодной для крупных предприятий с большими объемами данных.
• Однопользовательская ориентация: Имеет серьезные ограничения при полноценной многопользовательской работе, что может привести к блокировкам и снижению производительности при одновременном доступе нескольких пользователей.
• Производительность: Снижается при росте объемов данных и числа пользователей.
• Масштабируемость: Практически отсутствует. Не предназначена для роста.
• Информационная безопасность: Ограниченные средства защиты данных по сравнению с корпоративными СУБД.
• Кроссплатформенность: Работает только под управлением ОС Windows.

Применение для ООО «Оригами»: Microsoft Access может быть рассмотрена только для очень малых отделов с минимальным объемом товарных позиций и небольшим числом пользователей (1-2 человека), где требования к производительности и масштабируемости крайне низки. Для полноценной АИС учета товаров в динамично развивающейся компании она не подходит.

Microsoft SQL Server

Плюсы:

• Масштабируемость: Предназначена для работы с базами данных масштаба предприятия, способна обрабатывать огромные объемы данных и поддерживать тысячи одновременно работающих пользователей. Технология MS SQL AlwaysOn позволяет обрабатывать более 100 000 одновременно работающих пользователей за счет распределения нагрузки по чтению между репликами.
• Высокая производительность: Мощные инструменты оптимизации производительности (Store Query, Advisor for Database Engine Tuning, оптимизация дискового хранилища для таблиц, оптимизированных для памяти).
• Надежность и отказоустойчивость: Поддержка кластеризации, репликации, механизмов AlwaysOn для обеспечения высокой доступности и аварийного восстановления.
• Интеграция с продуктами Microsoft: Отличная совместимость с другими продуктами Microsoft (Windows Server, .NET, Azure).
• Комплексные средства безопасности: Широкий набор функций для защиты данных, аудита, шифрования.
• Развитые средства администрирования: Мощная среда SQL Server Management Studio для управления и мониторинга.
• Кроссплатформенность: Современные версии SQL Server могут работать не только на Windows Server (например, Windows Server 2019), но и на Linux.

Минусы:

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

Применение для ООО «Оригами»: SQL Server является отличным кандидатом для АИС учета товаров. Его масштабируемость, производительность и надежность идеально подходят для растущего предприятия с потенциально большим объемом данных и множеством пользователей. Интеграция с Windows-инфраструктурой, если таковая уже имеется, будет дополнительным преимуществом.

Oracle Database

Плюсы:

• Кроссплатформенность: Работает практически на любой существующей операционной системе, включая Windows Server и различные дистрибутивы Linux (Oracle Linux), что обеспечивает гибкость в выборе инфраструктуры.
• Высочайшая производительность и масштабируемость: Мировой лидер среди корпоративных СУБД, способный работать с петабайтами данных и миллионами транзакций в секунду.
• Надежность и доступность: Передовые технологии кластеризации (RAC — Real Application Clusters), репликации и аварийного восстановления.
• Расширенные возможности безопасности: Комплексные средства защиты данных, аудита, шифрования на всех уровнях.
• Функциональность: Богатый набор встроенных функций, поддержка различных типов данных, пространственных данных, XML и т.д.
• Глобальная поддержка: Обширная экосистема партнеров и квалифицированных специалистов по всему миру.

Минусы:

• Высокая стоимость: Самая дорогая СУБД из рассмотренных, как по стоимости лицензий, так и по стоимости поддержки.
• Сложность: Требует высококвалифицированных DBA (администраторов баз данных) для установки, настройки, оптимизации и обслуживания.
• Ресурсоемкость: Очень требовательна к аппаратным ресурсам.

Применение для ООО «Оригами»: Oracle Database представляет собой мощное, но дорогостоящее решение. Если ООО «Оригами» является крупным предприятием с критически важными требованиями к сверхвысокой доступности, производительности и способно инвестировать в высококвалифицированных специалистов и дорогостоящие лицензии, то Oracle может быть рассмотрен. В противном случае, для большинства средних и даже крупных предприятий, SQL Server предлагает оптимальное соотношение цены и качества.

Вывод по выбору СУБД для ООО «Оригами»:

Учитывая специфику учета товаров, потребность в многопользовательском доступе, потенциальный рост объемов данных и необходимость обеспечения надежности, Microsoft SQL Server выглядит наиболее оптимальным выбором для АИС учета товаров ООО «Оригами». Он предоставляет корпоративный уровень функциональности, масштабируемости и безопасности при более доступной стоимости владения по сравнению с Oracle, а также отличную интеграцию с продуктами Microsoft, что может быть преимуществом для многих компаний.

Оценка экономической эффективности внедрения АИС учета товаров

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

Методы и критерии оценки экономической эффективности IT-проектов

Экономическое обоснование целесообразности внедрения АИС — это процесс, который должен предшествовать ее внедрению. Он представляет собой оценку результатов и затрат на создание и развитие системы, помогая ответить на главный вопрос: «Будет ли эта инвестиция прибыльной?».

Различают два основных вида эффективности:

1. Расчетная эффективность: Определяется на стадии проектирования. Это прогнозный показатель, основанный на анализе потенциальных выгод и затрат.
2. Фактическая эффективность: Оценивается по результатам внедрения и эксплуатации системы. Она позволяет подтвердить или скорректировать первоначальные прогнозы.

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

Экономический эффект от внедрения АИС традиционно подразделяют на:

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

Методы оценки экономической эффективности IT-проектов:

Методы оценки делятся на три основные группы:

1. Традиционные (финансовые/количественные) методы: Основаны на математических расчетах и выражении эффекта в денежном эквиваленте. Все они базируются на принципе дисконтирования — приведении будущих денежных потоков к текущему моменту времени, учитывая изменение стоимости денег во времени.
   • Метод чистой приведенной стоимости (Net Present Value, NPV): Сумма дисконтированных денежных потоков (притоков и оттоков) проекта за весь его жизненный цикл. Если NPV > 0, проект считается экономически эффективным.
   • Внутренняя норма доходности (Internal Rate of Return, IRR): Ставка дисконтирования, при которой NPV проекта равен нулю. Проект считается эффективным, если IRR выше стоимости капитала.
   • Срок окупаемости инвестиций (Payback Period): Период времени, за который первоначальные инвестиции полностью возмещаются за счет чистых денежных потоков от проекта.

Формула ожидаемого экономического эффекта:

Для оценки годовой экономии от внедрения АИС можно использовать следующую формулу:

Эг = (Тб + Ен ⋅ Кб) − (Тв + Ен ⋅ Кв)

Где:

• Э_г — годовая экономия (экономический эффект).
• Т_б — текущие затраты до внедрения АИС (например, зарплата сотрудников, занятых ручным учетом, расходы на бумажный документооборот).
• Е_н — нормативный коэффициент эффективности капитальных вложений (отражает альтернативную стоимость капитала, обычно 0.15-0.2).
• К_б — капитальные затраты до внедрения (например, стоимость существующего оборудования, если оно будет заменено или модернизировано).
• Т_в — текущие затраты после внедрения АИС (например, зарплата меньшего числа сотрудников, занятых в учете, расходы на обслуживание АИС, лицензии).
• К_в — капитальные затраты после внедрения (стоимость разработки и внедрения АИС, закупка нового оборудования).

Пример расчета:

Предположим, для ООО «Оригами»:

• Текущие затраты на ручной учет (Т_б) = 1 500 000 руб./год.
• Капитальные затраты до внедрения (К_б) = 100 000 руб. (например, на устаревшее ПО).
• Нормативный коэффициент (Е_н) = 0.15.
• Текущие затраты после внедрения (Т_в) = 900 000 руб./год (за счет сокращения штата и оптимизации).
• Капитальные затраты на внедрение АИС (К_в) = 2 000 000 руб.

Эг = (1 500 000 + 0.15 ⋅ 100 000) − (900 000 + 0.15 ⋅ 2 000 000) = (1 500 000 + 15 000) − (900 000 + 300 000) = 1 515 000 − 1 200 000 = 315 000 руб./год.

Таким образом, годовая экономия составляет 315 000 рублей. Дальнейшие расчеты NPV и Payback Period покажут срок окупаемости и чистую прибыль.

2. Качественные методы: Дополняют количественные расчеты, позволяя учесть субъективные оценки и неявные выгоды. Эти методы фокусируются на ценности бизнес-процессов, персонала и стратегическом развитии.
3. Вероятностные методы: Используются для оценки рисков и неопределенностей проекта.

Комплексное применение этих методов позволит ООО «Оригами» получить полную картину экономической целесообразности внедрения АИС учета товаров.

Качественные методы оценки и учет неявных выгод

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

Одной из наиболее известных и эффективных качественных методик является Система сбалансированных показателей (Balanced Scorecard, BSC). BSC — это стратегическая система управления, которая фокусируется не только на финансовых показателях, но и на формализации целей проекта, организации и стратегическом развитии. Она рассматривает эффективность деятельности с четырех ключевых перспектив:

1. Финансы: Традиционные финансовые показатели (прибыль, рентабельность, ROI).
2. Клиенты: Удовлетворенность клиентов, лояльность, доля рынка.
3. Внутренние бизнес-процессы: Эффективность и качество операционной деятельности.
4. Обучение и развитие: Способность компании к инновациям, обучению персонала, развитию новых компетенций.

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

Другие качественные показатели эффективности проекта:

• Коэффициент достижения цели: Определяется как соотношение фактически достигнутых целей проекта к запланированным. Например, если одной из целей было «снизить ошибки при отгрузке на 50%», а фактическое снижение составило 40%, то коэффициент будет 0.8.
• Коэффициент роста удовлетворенности пользователей: Измеряется через опросы или интервью до и после внедрения системы. Повышение удовлетворенности персонала АИС напрямую коррелирует с ее эффективностью.
• Коэффициент вовлеченности пользователей: Оценивает, насколько активно сотрудники используют систему, насколько они заинтересованы в ее развитии и предоставлении обратной связи. Высокая вовлеченность — признак успешного внедрения.
• Сокращение сроков составления отчетов: Например, если раньше на подготовку ежемесячного отчета по остаткам уходило 8 часов, а теперь 1 час, это значительная неявная выгода.
• Повышение качества работ: Меньшее количество пересортицы, ошибок при формировании накладных, что ведет к снижению рекламаций и повышению репутации.
• Сокращение документооборота: Переход от бумажных документов к электронным, что экономит не только бумагу, но и время на их обработку и хранение.

Учет ROI для ERP-систем на горизонте не менее пяти лет:

Важно отметить, что при расчете срока окупаемости инвестиций (ROI) для сложных систем, таких как ERP (а АИС учета товаров может быть частью или основой для ERP), рекомендуется учитывать временные рамки не менее пяти лет. Это объясняется тем, что:

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

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

Информационная безопасность и правовое регулирование АИС

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

Основные угрозы и меры защиты информации в АИС

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

• Техногенные аварии: Сбои оборудования, отключение электроэнергии, стихийные бедствия.
• Вредоносное ПО: Вирусы, трояны, программы-вымогатели.
• Хакерские атаки: Целенаправленные попытки взлома систем извне.
• Хищение данных инсайдерами: Злонамеренные действия сотрудников или бывших сотрудников.
• Человеческий фактор: Ошибки пользователей, небрежное обращение с данными.

Основные задачи по защите информации (триада CIA — Confidentiality, Integrity, Availability):

1. Конфиденциальность: Недоступность информации третьим лицам. Это означает, что данные должны быть доступны только авторизованным пользователям и системам.
2. Целостность: Гарантия того, что данные являются точными, полными и не были изменены несанкционированным образом. Изменение данных возможно только лицами с соответствующим допуском.
3. Доступность: Обеспечение возможности получения необходимых данных пользователем и бесперебойного функционирования системы, когда это необходимо.

Меры защиты информации в АИС включают:

1. Аппаратные средства защиты:
   • Контроль физического доступа к оборудованию: Размещение серверов и рабочих станций в защищенных помещениях, использование систем контроля доступа (СКД), видеонаблюдения.
   • Источники бесперебойного питания (ИБП): Для защиты от перебоев в электроснабжении.
   • Резервирование оборудования: Дублирование критически важных компонентов (серверов, систем хранения данных) для обеспечения отказоустойчивости.
2. Программные средства защиты:
   • Идентификация и аутентификация пользователей: Уникальные логины и надежные пароли, двухфакторная аутентификация.
   • Авторизация и контроль доступа: Строгое разграничение прав доступа к функциям системы и данным на основе ролей пользователей (например, менеджер склада может только просматривать остатки, а администратор — изменять цены).
   • Шифрование данных: Как при хранении (на дисках), так и при передаче по сети (SSL/TLS).
   • Антивирусное ПО и системы обнаружения вторжений (IDS/IPS): Для защиты от вредоносных программ и атак.
   • Механизмы резервного копирования и восстановления данных: Регулярное создание бэкапов и тестирование процедур восстановления.
   • Журналирование и аудит: Ведение подробных записей обо всех операциях, попытках доступа, изменениях данных для анализа инцидентов и выявления аномалий.
3. Организационные меры защиты:
   • Утверждение внутренних нормативных документов: Регламенты по обработке данных, доступу к АИС, политике паролей, порядку действий при инцидентах.
   • Создание режима коммерческой тайны: Определение перечня сведений, составляющих коммерческую тайну, и установление правил работы с ними.
   • Обучение персонала: Регулярные тренинги по основам информационной безопасности, правилам работы с конфиденциальной информацией и поведению при угрозах.
   • Контроль физического доступа: Размещение рабочих станций в замкнутом пространстве, создание пропускной системы для посетителей.
   • Разработка плана реагирования на инциденты: Четкий алгоритм действий при обнаружении угроз или нарушениях безопасности.

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

Нормативно-правовая база РФ в области информационной безопасности

В Российской Федерации действует обширная нормативно-правовая база, регламентирующая вопросы информационной безопасности, которая должна неукоснительно соблюдаться при разработке и эксплуатации АИС. Для ООО «Оригами» особенно актуальны следующие документы:

1. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»: Регулирует сбор, хранение, обработку, использование и защиту персональных данных граждан РФ. Если АИС учета товаров будет содержать данные о клиентах или сотрудниках, компания обязана строго соблюдать требования этого закона (например, получать согласие на обработку, обеспечивать конфиденциальность, применять сертифицированные средства защиты).
2. Федеральный закон от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации»: Устанавливает правовые основы регулирования отношений в сфере информации, информационных технологий и защиты информации, включая принципы создания и эксплуатации информационных систем.
3. Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи»: Регулирует использование электронных подписей в электронном документообороте, что может быть актуально при интеграции АИС с внешними системами или для внутреннего утверждения документов.
4. Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» (ФЗ-187): Этот закон касается компаний, работающих в сферах, критически важных для государства (например, транспорт, энергетика, банки, здравоохранение). Если ООО «Оригами» попадает под определение субъекта критической информационной инфраструктуры, то оно обязано:
   • Сообщать об инцидентах в Государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА).
   • Использовать только сертифицированное ПО и оборудование.
   • Подключаться к ГосСОПКА.
5. Указ Президента РФ от 05.12.2016 № 646 «Об утверждении Доктрины информационной безопасности Российской Федерации»: Этот документ определяет стратегические цели и задачи государственной политики в области обеспечения информационной безопасности. Он является базовым ориентиром для всех организаций в РФ в вопросах защиты информации, подчеркивая важность конфиденциальности, целостности, доступности информации и противодействия угрозам в информационном пространстве.

Дополнительные нормативные документы и стандарты:

• ГОСТы по информационной безопасности: Например, ГОСТ Р 50922-2006 «Защита информации. Основные термины и определения», ГОСТ Р 51583-2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении».
• Требования ФСТЭК России и ФСБ России: Эти ведомства разрабатывают методические документы и устанавливают требования к системам защиты информации, особенно для государственных и критически важных объектов.

Необходимость внутренних нормативных документов и обучения персонала:

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

• Политика информационной безопасности.
• Положение о коммерческой тайне.
• Регламенты работы с персональными данными.
• Инструкции для пользователей и администраторов системы.

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

Таким образом, комплексный подход к информационной безопасности АИС учета товаров, основанный на детальном анализе угроз, применении адекватных мер защиты и строгом соблюдении актуальной нормативно-правовой базы РФ, является залогом надежности и устойчивости системы ООО «Оригами».

Заключение

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

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

Основные выводы по разработанной методологии:

1. Теоретические основы и жизненный цикл: Дано четкое определение АИС, обоснована ее эффективность, особенно на крупных предприятиях. Детально рассмотрены стандартизированные методологии жизненного цикла разработки (ISO/IEC 12207, ГОСТ Р ИСО/МЭК 12207-99, СТБ ISO/IEC/IEEE 12207-2023, ГОСТ Р 57193-2016) и стадии проектирования АС по ГОСТ 34.601-90, что обеспечивает методологическую строгость и соответствие лучшим практикам.
2. Методологии проектирования и моделирования: Проанализированы структурный (SADT/IDEF0) и объектно-ориентированный (UML) подходы, их принципы и применимость для АИС учета товаров. Особое внимание уделено BPMN как мощной нотации для моделирования бизнес-процессов, ориентированной на интеграцию бизнес-анализа и ИТ.
3. Требования к АИС: Сформулирован комплекс функциональных, нефункциональных (производительность, надежность, масштабируемость) и эргономических требований, обеспечивающих полноту спецификации и ориентированность на пользователя.
4. Проектирование базы данных: Подробно описаны принципы нормализации реляционных баз данных (1НФ, 2НФ, 3НФ) и методология построения ER-диаграмм, являющихся фундаментом для создания эффективной и целостной БД.
5. Выбор технологических решений: Проведен многопараметрический анализ критериев выбора СУБД, а также сравнительный анализ Microsoft Access, Microsoft SQL Server и Oracle Database. Обоснован выбор Microsoft SQL Server как наиболее оптимального решения для ООО «Оригами» с учетом масштабируемости, производительности и стоимости владения.
6. Оценка экономической эффективности: Представлены традиционные финансовые методы (NPV, IRR, Payback) с приведением формулы ожидаемого экономического эффекта, а также качественные методы оценки (BSC, коэффициенты достижения цели, удовлетворенности и вовлеченности). Подчеркнута важность учета ROI для ERP-систем на горизонте не менее пяти лет.
7. Информационная безопасность и правовое регулирование: Определены основные угрозы и меры защиты информации (конфиденциальность, целостность, доступность), а также детально рассмотрена актуальная нормативно-правовая база РФ (ФЗ-152, ФЗ-149, ФЗ-63, ФЗ-187, Доктрина информационной безопасности РФ, ГосСОПКА).

Перспективы дальнейшего развития АИС учета товаров:

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

• Интеграции с внешними системами: CRM, системами лояльности, электронными торговыми площадками.
• Внедрения технологий искусственного интеллекта: Для прогнозирования спроса, оптимизации логистики, автоматического выявления аномалий в учете.
• Разработки мобильных приложений: Для сотрудников склада и менеджеров по продажам, обеспечивающих доступ к системе в любом месте и в любое время.
• Расширения аналитического функционала: Внедрение BI-инструментов для глубокого анализа данных и поддержки стратегического планирования.

В конечном итоге, дипломная работа по созданию автоматизированной информационной системы учета товаров для ООО «Оригами» представляет собой не просто академический проект, а реальный вклад в повышение конкурентоспособности и устойчивого развития компании в условиях динамичного рынка.

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

1. Шумаков, П. В. Руководство разработчика баз данных / П. В. Шумаков, В. В. Фаронов. — Москва: Нолидж, 2000. — 635 с.
2. Базы данных: модели, разработка, реализация / Т. Карпова. — Санкт-Петербург: Питер, 2001. — 304 с.
3. Хабракен, Дж. Microsoft Access 2000. Шаг за шагом / Дж. Хабракен. — Москва: АСТ, Астрель, 2004. — 350 с.
4. Тимошок, Т. В. Microsoft Access 2002. Самоучитель / Т. В. Тимошок. — Москва: Диалектика, 2004. — 352 с.
5. Microsoft Access 2003. Русская версия (+ CD-ROM). — Москва: Эком, 2008. — 432 с.
6. Степанов, В. Microsoft Access 2003 для начинающих / В. Степанов. — Санкт-Петербург: Аквариум-Принт, Дом печати — Вятка, 2006. — 128 с.
7. Мак-Дональд, М. Access 2007. Недостающее руководство / М. Мак-Дональд. — Санкт-Петербург: Русская Редакция, БХВ-Петербург, 2007. — 784 с.
8. Сергеев, А. Access 2007. Новые возможности / А. Сергеев. — Москва: Питер, 2008. — 176 с.
9. Глушаков, С. В. Microsoft Access 2007. Лучший самоучитель / С. В. Глушаков, А. С. Сурядный, М. И. Шумилов. — Москва: АСТ, АСТ Москва, 2008. — 448 с.
10. Голышева, А. В. Access 2007 без воды. Все, что нужно для уверенной работы / А. В. Голышева, И. А. Клеандрова, Р. Г. Прокди. — Москва: Наука и техника, 2008. — 192 с.
11. Кошелев, В. Е. Access 2007. Эффективное использование / В. Е. Кошелев. — Санкт-Петербург: Бином-Пресс, 2009. — 590 с.
12. Смирнова, О. В. Access 2007 на практике / О. В. Смирнова. — Москва: Феникс, 2009. — 160 с.
13. Кронан, Дж. Microsoft Access 2007 / Дж. Кронан, Б. Сандберг. — Москва: НТ Пресс, 2009. — 384 с.
14. Сеннов, А. Access 2010 / А. Сеннов. — Москва: Питер, 2010. — 288 с.
15. Access 2010 для чайников / Л. Ульрих Фуллер, К. Кук. — Санкт-Петербург: Вильямс, 2011. — 384 с.
16. ГОСТ Р 57193-2016. Системная и программная инженерия. Процессы жизненного цикла систем. – Введ. 2017–09–01. – Москва : Стандартинформ, 2016. – URL: https://docs.cntd.ru/document/1200140232 (дата обращения: 25.10.2025).
17. ГОСТ Р 56923-2016. Информационные технологии. Системная и программная инженерия. Управление жизненным циклом. Часть 3. Руководство по применению ИСО/МЭК 12207 (Процессы жизненного цикла программных средств). – Введ. 2017–09–01. – Москва : Стандартинформ, 2016. – URL: https://allgosts.ru/03/080/gost_r_56923-2016 (дата обращения: 25.10.2025).
18. СТБ ISO/IEC/IEEE 12207-2023. Разработка систем и программного обеспечения. Процессы жизненного цикла программного обеспечения. – Введ. 2023–06–01. – Минск : Госстандарт, 2023. – URL: https://bntu.by/scientific-library/standarts/stb-iso-iec-ieee-12207-2023 (дата обращения: 25.10.2025).
19. Современные концепции объектного проектирования информационных систем // Cyberleninka.ru. — URL: https://cyberleninka.ru/article/n/sovremennye-kontseptsii-obektnogo-proektirovaniya-informatsionnyh-sistem (дата обращения: 25.10.2025).
20. СТРУКТУРНЫЙ И ОБЪЕКТНО-ОРИЕНТИРОВАННЫЙ ПОДХОДЫ К ПРОЕКТИРОВАНИЮ ИНФОРМАЦИОННЫХ СИСТЕМ // Cyberleninka.ru. — URL: https://cyberleninka.ru/article/n/strukturnyy-i-obektno-orientirovannyy-podhody-k-proektirovaniyu-informatsionnyh-sistem (дата обращения: 25.10.2025).
21. Разработка автоматизированной системы учета заказов ООО «ИнформТе» // Core.ac.uk. — URL: https://core.ac.uk/download/pdf/196924823.pdf (дата обращения: 25.10.2025).
22. Нефункциональные требования // Ensi.ru. — URL: https://ensi.ru/blog/nefunkcionalnye-trebovaniya/ (дата обращения: 25.10.2025).
23. Что такое нефункциональные требования: типы, примеры и подходы // Visuresolutions.com. — URL: https://visuresolutions.com/ru/what-are-non-functional-requirements-types-examples-and-approaches/ (дата обращения: 25.10.2025).
24. Что такое функциональные требования: примеры и шаблоны // Visuresolutions.com. — URL: https://visuresolutions.com/ru/what-are-functional-requirements-examples-and-templates/ (дата обращения: 25.10.2025).
25. Функциональные и нефункциональные требования (с примерами) // Visuresolutions.com. — URL: https://visuresolutions.com/ru/functional-and-non-functional-requirements-with-examples/ (дата обращения: 25.10.2025).
26. Нефункциональные требования к системе: что такое, примеры, что входит // Kaiten.ru. — URL: https://kaiten.ru/blog/non-functional-requirements/ (дата обращения: 25.10.2025).
27. Функциональные и нефункциональные требования к ПО: что важно знать // Kaiten.ru. — URL: https://kaiten.ru/blog/functional-and-non-functional-requirements/ (дата обращения: 25.10.2025).
28. Стадии создания автоматизированных систем // Tehpis.ru. — URL: https://tehpis.ru/stadii-sozdaniya-avtomatizirovannyx-sistem/ (дата обращения: 25.10.2025).
29. ЭТАПЫ РАЗРАБОТКИ АИС // Studfile.net. — URL: https://studfile.net/preview/791834/page:18/ (дата обращения: 25.10.2025).
30. Ступин, А. А. Тема 3.1. Классификация функциональной части АИС // Studopedia.su. — URL: https://studopedia.su/13_16885_stupin-aa-tema—klassifikatsiya-funktsionalnoy-chasti-ais.html (дата обращения: 25.10.2025).
31. Центр цифрового развития этапы разработки информационных систем // D-r.ru. — URL: https://d-r.ru/blog/it-process/etapy-razrabotki-informacionnyh-sistem.html (дата обращения: 25.10.2025).
32. ПРОЕКТИРОВАНИЕ ИС НА ОСНОВЕ СТРУКТУРНОГО ПОДХОДА // Intuit.ru. — URL: http://www.intuit.ru/studies/courses/2193/648/lecture/13928?page=4 (дата обращения: 25.10.2025).
33. Глава 8. Структурный подход проектирования информационных систем (ис) // Studfile.net. — URL: https://studfile.net/preview/4308064/page:13/ (дата обращения: 25.10.2025).
34. Структурный подход к проектированию ИС // Citforum.ru. — URL: https://citforum.ru/consulting/sa/sa2/ (дата обращения: 25.10.2025).
35. Объектно-ориентированное проектирование ис // Studfile.net. — URL: https://studfile.net/preview/6075936/ (дата обращения: 25.10.2025).
36. ПРОЕКТИРОВАНИЕ ИС НА ОСНОВЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА // Studopedia.su. — URL: https://studopedia.su/13_15197_proektirovanie-is-na-osnove-obektno-orientirovannogo-podhoda.html (дата обращения: 25.10.2025).
37. Лекция 35. Объектно-ориентированное проектирование ЭИС // Studfile.net. — URL: https://studfile.net/preview/6770289/page:11/ (дата обращения: 25.10.2025).
38. Экономическая эффективность информационных систем // Studfile.net. — URL: https://studfile.net/preview/13018898/page:13/ (дата обращения: 25.10.2025).
39. Как оценить эффективность IT-решения: ROI, KPI и бизнес-метрики // Nomium.ru. — URL: https://nomium.ru/blog/kak-ocenit-effektivnost-it-resheniya-roi-kpi-i-biznes-metriki (дата обращения: 25.10.2025).
40. Нормативно-правовая база в области защиты информации // Digital.gov.ru. — URL: https://digital.gov.ru/ru/activity/directions/858/ (дата обращения: 25.10.2025).
41. Технико-экономическое обоснование создания автоматизированной информационной системы // Studfile.net. — URL: https://studfile.net/preview/791834/page:24/ (дата обращения: 25.10.2025).
42. Нотации моделирования бизнес-процессов // Businessstudio.ru. — URL: https://www.businessstudio.ru/articles/notatsii-modelirovaniya-biznes-protsessov/ (дата обращения: 25.10.2025).
43. Методический подход оценки экономической эффективности ИТ-проектов // Cyberleninka.ru. — URL: https://cyberleninka.ru/article/n/metodicheskiy-podhod-otsenki-ekonomicheskoy-effektivnosti-it-proektov (дата обращения: 25.10.2025).
44. Описание нормализации базы данных // Support.microsoft.com. — URL: https://support.microsoft.com/ru-ru/office/%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D0%B8-%D0%B1%D0%B0%D0%B7%D1%8B-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-e63a339a-7ac8-410a-8646-95e263c9b740 (дата обращения: 25.10.2025).
45. Технико-экономическое обоснование использования автоматизированной информационной системы учета и контроля на примере ООО // Core.ac.uk. — URL: https://core.ac.uk/download/pdf/196924823.pdf (дата обращения: 25.10.2025).
46. Нормативно-правовое обеспечение информационной безопасности в России // Studfile.net. — URL: https://studfile.net/preview/2655182/ (дата обращения: 25.10.2025).
47. Современные подходы к оценке эффективности информационных систем в бизнесе // Cyberleninka.ru. — URL: https://cyberleninka.ru/article/n/sovremennye-podhody-k-otsenke-effektivnosti-informatsionnyh-sistem-v-biznese (дата обращения: 25.10.2025).
48. 5 ключевых законов РФ об информационной безопасности: как хранить и защищать данные // Vk.cloud. — URL: https://vk.cloud/blog/5-laws-on-information-security-in-russia/ (дата обращения: 25.10.2025).
49. Справочник законодательства РФ в области информационной безопасности (версия 03.09.2025) // Habr.com. — URL: https://habr.com/ru/articles/433066/ (дата обращения: 25.10.2025).
50. Нотации моделирования бизнес-процессов: основные виды — IDEF, EPC, BPMN и советы по их выбору // Practicum.yandex.ru. — URL: https://practicum.yandex.ru/blog/notacii-modelirovaniya-biznes-processov/ (дата обращения: 25.10.2025).
51. Что такое нотации бизнес-процессов. Их типы IDEF0, EPC, BPMN // Comindware.com. — URL: https://comindware.com/ru/blog/chto-takoe-notatsii-biznes-protsessov-ikh-tipy-idef0-epc-bpmn/ (дата обращения: 25.10.2025).
52. Примеры и принципы нормализации реляционных баз данных (БД) // Decosys.ru. — URL: https://decosys.ru/blog/primery-i-principy-normalizacii-relyacionnyh-baz-dannyh-bd/ (дата обращения: 25.10.2025).
53. Что такое нотации для моделирования бизнес-процессов: обзор BPMN, IDEF, EPC. Как выбрать подходящую и нужно ли это вашей компании // Cionavigator.ru. — URL: https://cionavigator.ru/blog/notatsii-modelirovaniya-biznes-protsessov-obzor-bpmn-idef-epc/ (дата обращения: 25.10.2025).
54. Нормализация базы данных: для чего нужна нормализованная бд // Gitverse.ru. — URL: https://gitverse.ru/blog/normalization-database-what-for-normalized-database/ (дата обращения: 25.10.2025).
55. Что такое нормализация баз данных? // 1cbit.ru. — URL: https://1cbit.ru/blog/chto-takoe-normalizatsiya-baz-dannykh/ (дата обращения: 25.10.2025).
56. Нормализация баз данных SQL и зачем её нормализовать // Decosys.ru. — URL: https://decosys.ru/blog/normalizaciya-baz-dannyh-sql-i-zachem-ee-normalizovat/ (дата обращения: 25.10.2025).
57. Защита информации в автоматизированных системах // Tign.ru. — URL: https://tign.ru/blog/zashhita-informacii-v-avtomatizirovannyh-sistemah/ (дата обращения: 25.10.2025).
58. Защита информации в автоматизированных информационных системах // Searchinform.ru. — URL: https://www.searchinform.ru/infosecurity/blog/zashchita-informatsii-v-avtomatizirovannykh-informatsionnykh-sistemakh/ (дата обращения: 25.10.2025).
59. Методика расчета эффективности проектов по оптимизации процессов // Project.economy.gov.ru. — URL: https://project.economy.gov.ru/methodology/method/ (дата обращения: 25.10.2025).
60. Моделирование бизнес-процессов: цели, этапы, инструменты и примеры // Elma-bpm.ru. — URL: https://www.elma-bpm.ru/blog/modelirovanie-biznes-protsessov-celi-etapy-instrumenty-i-primery/ (дата обращения: 25.10.2025).
61. Экономическое обоснование разработки информационной системы на примере ИС «Учет услуг по найму жилья для общежития» // Cyberleninka.ru. — URL: https://cyberleninka.ru/article/n/ekonomicheskoe-obosnovanie-razrabotki-informatsionnoy-sistemy-na-primere-is-uchet-uslug-po-naymu-zhilya-dlya-obschezhitiya (дата обращения: 25.10.2025).
62. Методы определения экономического эффекта от ИТ-проекта // Iteam.ru. — URL: https://www.iteam.ru/publications/it/section_30/article_3582/ (дата обращения: 25.10.2025).
63. Сравнительный анализ СУБД // Studfile.net. — URL: https://studfile.net/preview/5753086/page:3/ (дата обращения: 25.10.2025).
64. Методы оценки эффективности ИС предприятия // Nauchny-aspect.ru. — URL: https://nauchny-aspect.ru/upload/iblock/c38/c387b370617300f283556447831f2420.pdf (дата обращения: 25.10.2025).
65. Пример разработки ER-модели — документация RedDatabaseSQLBook 0.1 // Reddatabasesqlbook.readthedocs.io. — URL: https://reddatabasesqlbook.readthedocs.io/ru/latest/dbdesign/erd.html (дата обращения: 25.10.2025).
66. Считаем эффективность ИТ-проектов // Bit.ru. — URL: https://bit.ru/blog/schitaem-effektivnost-it-proektov/ (дата обращения: 25.10.2025).
67. Критерии выбора СУБД при создании информационных систем // Citforum.ru. — URL: https://citforum.ru/database/articles/dbms_selection_criteria/ (дата обращения: 25.10.2025).
68. СУБД: что такое системы управления базами данных, виды, где используются, для чего нужны // Disgroup.ru. — URL: https://www.disgroup.ru/blog/chto-takoe-subd-vidy-i-primenenie (дата обращения: 25.10.2025).
69. ОЦЕНКА ЭКОНОМИЧЕСКОГО ЭФФЕКТА ВНЕДРЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ // Cyberleninka.ru. — URL: https://cyberleninka.ru/article/n/otsenka-ekonomicheskogo-effekta-vnedreniya-informatsionnoy-sistemy (дата обращения: 25.10.2025).
70. ER-диаграммы для системы онлайн-покупок: Полное руководство // Edrawsoft.com. — URL: https://www.edrawsoft.com/ru/er-diagrams-for-online-shopping-system.html (дата обращения: 25.10.2025).
71. Критерии выбора субд при создании аис // Studfile.net. — URL: https://studfile.net/preview/5753086/page:7/ (дата обращения: 25.10.2025).
72. Критерии выбора по аис бу // Studfile.net. — URL: https://studfile.net/preview/5753086/page:9/ (дата обращения: 25.10.2025).
73. Сравнительная характеристика двух СУБД MS Access и SQL Server 2005 // Itfb.com.ua. — URL: https://itfb.com.ua/images/stories/files/accesssql.pdf (дата обращения: 25.10.2025).
74. Методы оценки эффективности систем защиты информационных систем // Cyberleninka.ru. — URL: https://cyberleninka.ru/article/n/metody-otsenki-effektivnosti-sistem-zaschity-informatsionnyh-sistem (дата обращения: 25.10.2025).
75. Как оценить эффективность информационной системы // Habr.com. — URL: https://habr.com/ru/articles/761168/ (дата обращения: 25.10.2025).
76. Сравнение типов данных Access и SQL Server // Support.microsoft.com. — URL: https://support.microsoft.com/ru-ru/office/%D1%81%D1%80%D0%B0%D0%B2%D0%BD%D0%B5%D0%BD%D0%B8%D0%B5-%D1%82%D0%B8%D0%BF%D0%BE%D0%B2-%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85-access-%D0%B8-sql-server-4b15099f-7a42-4217-062e-9d21c326d959 (дата обращения: 25.10.2025).
77. Лабораторная работа №1. Построение ER-диаграмы // Classmech.ru. — URL: https://classmech.ru/content/lab1-er-model (дата обращения: 25.10.2025).
78. Пример построения ER-модели и SQL-запросов к ней // Babok.school. — URL: https://babok.school/er-model-sql/ (дата обращения: 25.10.2025).
79. Рекомендации по обеспечению защиты общедоступной информации в информационных системах // Oac.gov.by. — URL: https://oac.gov.by/recommendations/rekomendatsii-po-obespecheniyu-zashchity-obshchedostupnoy-informatsii-v-informatsionnykh-sistemakh/ (дата обращения: 25.10.2025).
80. СРАВНИТЕЛЬНЫЙ АНАЛИЗ СОВРЕМЕННЫХ СУБД Системы управления базами д // Studfile.net. — URL: https://studfile.net/preview/10398030/page:2/ (дата обращения: 25.10.2025).
81. Сравнительный анализ систем управления базами данных // Scienceforum.ru. — URL: https://scienceforum.ru/2018/article/2018001851 (дата обращения: 25.10.2025).
82. Как выбрать СУБД для нового проекта – Продукты и технологии // It-world.ru. — URL: https://it-world.ru/it-technologies/development/kak-vybrat-subd-dlya-novogo-proekta.html (дата обращения: 25.10.2025).
83. Нормативные документы // Cryptosvyaz.ru. — URL: https://cryptosvyaz.ru/normativnye-dokumenty (дата обращения: 25.10.2025).
84. Перечень основных действующих документов в области защиты информации // Tadviser.ru. — URL: https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:%D0%9F%D0%B5%D1%80%D0%B5%D1%87%D0%B5%D0%BD%D1%8C_%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D1%8B%D1%85_%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D1%83%D1%8E%D1%89%D0%B8%D1%85_%D0%B4%D0%BE%D0%BA%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D0%BE%D0%B2_%D0%B2_%D0%BE%D0%B1%D0%BB%D0%B0%D1%81%D1%82%D0%B8_%D0%B7%D0%B0%D1%89%D0%B8%D1%82%D1%8B_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%B8 (дата обращения: 25.10.2025).