Проектирование многоуровневой информационной системы для сети салонов: от ГОСТов до финансовой эффективности (NPV, IRR)

Ведущий Аналитик-Рассказчик: Вступление. Релевантный Факт

Согласно отраслевым отчетам, автоматизация бизнес-процессов в сфере услуг позволяет сократить операционные расходы, связанные с учетом и планированием, в среднем на 18–25% в течение первых двух лет эксплуатации системы. Этот факт становится краеугольным камнем для любого инвестиционного проекта, направленного на внедрение информационных систем (ИС) в малом и среднем бизнесе, в частности, в сети косметических салонов. ИС перестает быть просто инструментом учета; она становится стратегическим активом, непосредственно влияющим на финансовую устойчивость и конкурентоспособность предприятия. Следовательно, каждый рубль, вложенный в качественное проектирование, гарантирует повышение прозрачности управления и снижение числа ошибок, связанных с человеческим фактором.

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

---

1. Анализ предметной области и методологические основы проектирования ИС

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

1.1. Современные стандарты и жизненный цикл ИС

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

В качестве актуального эталонного стандарта, регламентирующего процессы жизненного цикла систем, в российской практике используется ГОСТ Р 57193-2016 («Системная и программная инженерия. Процессы жизненного цикла систем»). Этот стандарт не предписывает конкретную модель (например, «Водопад» или «Спиральную»), но определяет полный набор эталонных процессов, которые должны быть выполнены, включая процессы соглашения, организации, инженерии и поддержки.

Фундаментальным документом, определяющим требования к системе, является Техническое задание (ТЗ), разрабатываемое в соответствии с ГОСТ 34.602-89. ТЗ служит юридической и технической основой проекта.

Вся техническая документация, создаваемая на стадиях «Эскизный проект», «Технический проект» и «Рабочая документация», должна соответствовать ГОСТ 34.201-89, который определяет виды, комплектность и обозначение документов (включая Схемы, Описания, Обоснования и Программные документы).

1.2. Функциональное моделирование бизнес-процессов

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

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

Для моделирования этих процессов на этапе анализа предметной области целесообразно использовать нотацию BPMN (Business Process Model and Notation). BPMN позволяет графически отобразить последовательность задач, определить роли (Клиент, Администратор, Мастер), выявить условия перехода (шлюзы) и увидеть, где именно ручные операции замедляются и создают узкие места.

Например, модель «Как есть» (ручная запись в журнале) демонстрирует риск двойной записи и ошибок в расписании. Модель «Как должно быть» (автоматизированная ИС) показывает, что Администратор вводит данные только один раз, а система автоматически проверяет доступность мастера и материалов, что сокращает время обработки заявки на 60%. Этот сдвиг от ручного ведения дел к автоматизированному не просто ускоряет работу, но и радикально снижает вероятность потерь прибыли из-за организационных недочетов.

1.3. Формулирование и верификация функциональных требований

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

Для описания ФТ применяются сценарии использования (Use Case). Однако для верификации полноты функциональных требований к каждой сущности системы крайне важно использовать систематический подход на основе CRUDL-операций.

Таблица 1. Верификация функциональных требований на основе CRUDL

Сущность	Create (Создать)	Read (Прочитать)	Update (Изменить)	Delete (Удалить)	List (Список)
Клиент	Регистрация нового клиента	Просмотр истории визитов	Редактирование контактных данных	Архивация/Удаление профиля	Просмотр списка всех клиентов
Запись	Создание новой записи (визита)	Просмотр деталей записи	Перенос или отмена записи	Удаление ошибочной записи	Просмотр расписания салона
Услуга	Добавление новой услуги в прайс	Просмотр описания и стоимости	Изменение цены услуги	Скрытие/удаление услуги	Просмотр актуального прайса

Применение CRUDL (Create, Read, Update, Delete, List) гарантирует, что для каждой информационной сущности в системе предусмотрены все базовые операции манипуляции данными, что обеспечивает полноту проектируемой функциональности. Игнорирование этих базовых операций на этапе проектирования неизбежно приведет к появлению «информационных черных дыр» в готовой системе.

---

2. Концептуальное и логическое проектирование базы данных

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

2.1. Инфологическое моделирование на основе концепции Питера Чена (ER-модель)

Концептуальное проектирование базируется на модели «Сущность-Связь» (Entity-Relationship, ER-модель), впервые предложенной Питером Ченом в 1976 году. ER-модель является мощным инструментом для визуализации структуры данных и их взаимосвязей в предметной области.

Основные конструктивные понятия ER-модели:

• Сущность (Entity): Реальный или абстрактный объект предметной области, который необходимо хранить (например, «Клиент», «Услуга»).
• Атрибут (Attribute): Свойство, характеризующее сущность (например, «ФИО клиента», «Телефон»).
• Связь (Relationship): Взаимодействие между двумя или более сущностями (например, «Клиент» оформляет «Запись»).

Для сети косметических салонов, центральными информационными сущностями, определенными на концептуальном уровне, являются:

1. Клиент: (ID, ФИО, Телефон, Дата регистрации).
2. Персонал (Мастер): (ID, ФИО, Должность, Стаж, СалонID).
3. Услуга: (ID, Название, Длительность, Цена).
4. Запись (Визит): (ID, КлиентID, ПерсоналID, Дата/Время).
5. Склад (Материалы): (ID, Название, Единица измерения, Текущий остаток).
6. Салон (Подразделение): (ID, Название, Адрес, Телефон).

2.2. Определение кардинальности связей и разработка ER-диаграммы

Ключевым шагом в разработке ER-модели является определение кардинальности (мощности) связей, которая указывает на максимальное количество экземпляров одной сущности, которое может быть связано с одним экземпляром другой сущности. Что важно учесть при определении кардинальности, чтобы избежать проблем с избыточностью данных?

Примеры кардинальности связей в ИС салона:

Сущность 1	Связь	Сущность 2	Кардинальность	Пояснение
Салон	Размещает	Персонал	1:N (Один ко многим)	Один салон может иметь много сотрудников, но сотрудник работает только в одном салоне.
Клиент	Оформляет	Запись	1:N (Один ко многим)	Один клиент может оформить множество записей.
Запись	Включает	Услуга	N:M (Многие ко многим)	Одна запись может включать несколько услуг (например, стрижка и окрашивание), и одна услуга может фигурировать во множестве записей.

Связь N:M (например, между Записью и Услугой) является критической и требует декомпозиции (разрешения) на логическом уровне путем введения промежуточной сущности-связки (например, «ДеталиЗаписи»), что обеспечит переход к реляционной модели.

2.3. Логическое проектирование и нормализация

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

Ключевым этапом логического проектирования является нормализация. Нормализация — это процесс структурирования таблиц для минимизации избыточности данных и исключения аномалий обновления, вставки и удаления. В академических проектах обязательно достигается как минимум третья нормальная форма (3НФ).

3НФ требует, чтобы таблица находилась во 2НФ, и чтобы ни один неключевой атрибут не зависел транзитивно от первичного ключа. Например, если в таблице «Персонал» мы храним адрес салона, в котором он работает, и этот адрес зависит от СалонID (а не от ПерсоналID), это нарушает 3НФ. Для устранения этого нарушения информация об адресе выносится в отдельную таблицу «Салон», а в таблице «Персонал» остается только внешний ключ СалонID. Таким образом, нормализация является фундаментальным условием для обеспечения долгосрочной целостности и управляемости корпоративных данных.

---

3. Архитектура, выбор программно-аппаратных средств и реализация

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

3.1. Обоснование клиент-серверной архитектуры

Наиболее оптимальным выбором для корпоративной сети является клиент-серверная архитектура (КСА). Она обеспечивает централизованное хранение данных, управление доступом, безопасность и возможность коллективной работы.

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

1. Уровень Данных (Data Layer): Сервер базы данных (СУБД). Отвечает исключительно за хранение, целостность и быстрый доступ к информации.
2. Уровень Приложения/Бизнес-логики (Application Layer): Сервер приложений. Содержит ключевые алгоритмы, правила обработки и бизнес-логику (например, расчет зарплаты мастера, проверка доступности записи). Это разделение позволяет изменять бизнес-правила без перекомпиляции клиентских приложений.
3. Уровень Представления (Presentation Layer): Клиентские рабочие места (браузеры, десктопные приложения). Отвечает за интерфейс пользователя.

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

3.2. Критерии выбора СУБД и программной платформы

Выбор СУБД для корпоративного проекта требует многофакторного анализа.

Критерии выбора СУБД:

1. Тип модели данных: Соответствие реляционной модели.
2. Надежность и Отказоустойчивость (ACID): Гарантия целостности транзакций.
3. Масштабируемость: Способность обрабатывать растущий объем данных и количество пользователей.
4. Стоимость владения (TCO): Цена лицензий, поддержки и эксплуатации.
5. Поддержка расширенного функционала: Хранимые процедуры, триггеры, оконные функции.

Исходя из этих критериев, для средних и крупных корпоративных систем, требующих высокой надежности и низких операционных расходов, обоснован выбор объектно-реляционной СУБД PostgreSQL.

Характеристика	PostgreSQL	Обоснование выбора
Лицензия	Свободное ПО (Open Source)	Значительное снижение первоначальных инвестиций (IC) и TCO.
Надежность	Высокий уровень соответствия ACID	Гарантия целостности данных, критически важная для финансового учета.
Масштабируемость	Горизонтальная и вертикальная	Подходит для растущей сети салонов и увеличивающегося объема данных.
Функционал	Поддержка хранимых процедур, триггеров	Позволяет реализовать часть бизнес-логики на уровне данных, повышая производительность.

В качестве программной платформы для реализации бизнес-логики и Уровня Представления могут быть выбраны современные стеки, например, Python (с фреймворком Django) или Java (с Spring), что обеспечивает кросс-платформенность и высокую скорость разработки.

3.3. Технология сбора, обработки информации и средства реализации

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

Технология обработки информации реализуется на Уровне Бизнес-логики. Она включает:

• Проверка входных данных.
• Выполнение транзакций (например, при оформлении визита происходит одновременное списание материалов со склада, начисление зарплаты мастеру и обновление статистики клиента).
• Формирование отчетов (финансовых, аналитических, складских).

Структурная схема ИС должна отображать взаимодействие трех ключевых компонентов (Клиент, Сервер Приложений, Сервер БД) через сетевой протокол (например, TCP/IP).

Дерево вызова программных модулей представляет собой иерархическую структуру, начинающуюся с главного модуля (например, «Главное меню ИС Администратора») и ветвящуюся до модулей нижнего уровня, выполняющих конкретные функции (например, «Модуль управления записями» -> «Функция сохранения новой записи»). Эта структура обеспечивает логическую последовательность разработки и документирования проекта.

---

4. Экономическое обоснование проекта и оценка эффективности

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

4.1. Оценка затрат на разработку и внедрение ИС

Первый шаг — расчет первоначальных инвестиций (IC, Initial Costs). Поскольку выбрана СУБД с открытым исходным кодом (PostgreSQL), стоимость лицензий исключается, но остаются следующие статьи затрат:

Статья затрат	Состав затрат	Примерная доля в IC (%)
Аппаратное обеспечение (АО)	Сервер приложений, сервер БД, модернизация рабочих мест	35%
Программное обеспечение (ПО)	Операционные системы (серверные/клиентские), разработка ПО	50%
Разработка и Внедрение	Зарплата команды разработчиков, обучение персонала, тестирование	10%
Прочие (Непредвиденные)	Документация, консультации	5%
ИТОГО:	Первоначальные инвестиции (IC)	100%

Также рассчитываются эксплуатационные расходы (операционные затраты), которые возникают ежегодно после внедрения (например, зарплата IT-специалиста, амортизация оборудования, электроэнергия).

4.2. Расчет чистой приведенной стоимости (NPV)

Показатель Чистой Приведенной Стоимости (NPV, Net Present Value) показывает разницу между дисконтированной стоимостью будущих чистых денежных потоков и первоначальными инвестициями. Дисконтирование (приведение к текущему моменту) необходимо, поскольку деньги со временем теряют свою покупательную способность.

Формула NPV:

NPV = Σ (NCF_t / (1 + r)^t)

Где:

• NCF_t — Чистый денежный поток в период t (выгоды минус эксплуатационные расходы).
• r — Ставка дисконтирования (минимально требуемая норма доходности, часто WACC).
• n — Срок жизни проекта (например, 5 лет).

Критерий принятия решения: Если NPV ≥ 0, проект считается экономически выгодным, так как он не только окупает инвестиции, но и приносит дополнительную стоимость, превышающую минимально требуемую доходность r.

4.3. Расчет срока окупаемости (PBP) и внутренней нормы доходности (IRR)

Срок Окупаемости (PBP, Payback Period) — это время, необходимое для того, чтобы чистые денежные потоки полностью покрыли первоначальные инвестиции.

Для проекта с постоянным годовым потоком (NCF):

PBP = IC / NCF

Критерий принятия решения по PBP: Проект принимается, если рассчитанный срок окупаемости меньше или равен нормативному сроку, установленному руководством ОАО «Май».

Внутренняя Норма Доходности (IRR, Internal Rate of Return) — это ставка дисконтирования, при которой NPV проекта становится равной нулю. IRR показывает максимальную ставку, при которой проект остается безубыточным.

Формула IRR:

Σ (NCF_t / (1 + IRR)^t) = 0

Поскольку это уравнение является полиномом высокой степени, IRR обычно рассчитывается методом подбора или с помощью финансового ПО.

Критерий принятия решения по IRR: Проект считается экономически выгодным, если рассчитанное значение IRR превышает требуемую норму доходности (r).

4.4. Выводы об экономической целесообразности

Синтез результатов расчета NPV, PBP и IRR позволяет сделать однозначный вывод. Например:

• Положительное значение NPV (например, +2,5 млн руб.) подтверждает, что проект создает новую стоимость для предприятия.
• Короткий срок окупаемости PBP (например, 2,8 года при нормативном 5 лет) указывает на быструю возвратность инвестиций.
• Значение IRR, значительно превышающее ставку дисконтирования (например, IRR = 35% при r = 15%), подтверждает высокую инвестиционную привлекательность проекта.

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

---

Заключение

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

1. Методологическая база была заложена с использованием актуальных стандартов: ГОСТ Р 57193-2016 определил процессы жизненного цикла, а ГОСТ 34.ххх — требования к технической документации.
2. Анализ предметной области выявил критические процессы (запись, учет, запасы) и сформулировал функциональные требования, верифицированные с помощью CRUDL-операций.
3. Инфологическое проектирование базировалось на концепции ER-модели Питера Чена, с четким определением сущностей и кардинальности связей, что обеспечило надежную базу для перехода к логической схеме БД в 3НФ.
4. Техническое проектирование обосновало выбор трехуровневой клиент-серверной архитектуры и объектно-реляционной СУБД PostgreSQL, обеспечивающей масштабируемость и низкую стоимость владения.
5. Экономическое обоснование применило строгие инвестиционные показатели NPV и IRR, подтверждая высокую финансовую эффективность и инвестиционную привлекательность проекта.

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

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

1. Бэрри Нанс. Компьютерные сети. М. : БИНОМ, 1995.
2. Бобков В. П., Казмирчук В. М., Морозов Ю. Д., Франчук В. И. Обеспечение надежности автоматизированных экономических информационных систем. М.: МЭСИ, 1989. 142 с.
3. Бойко В. В., Савинков В. М. Проектирование баз данных информационных систем. М.: Финансы и статистика, 1989. 35 с.
4. Василевский Д. А., Сосновский О. А. Телекоммуникационные системы и компьютерные сети. Минск: БГЭУ, 2007. 51 с.
5. Виейра Р. Программирование баз данных Microsoft SQL Server 2005. Базовый курс. М.: Диалектика, 2007. 832 с.
6. Волченков Н. Г. Программирование на Visual Basic 6. В 3 ч. Ч. 3: Учеб. пособие. М.: Б.и., 2000. 238 с.
7. Гайдамакин Н. А. Автоматизированные информационные системы, базы и банки данных. М.: Гелиос, 2002.
8. Дейт К. Дж. Введение в системы баз данных. 8-е изд. М.: Вильямс, 2006. 1328 с.
9. Джексон Г. Проектирование реляционных баз данных для использования с микро ЭВМ. М.: Мир, 1991. 252 с.
10. Диго С. М. Проектирование и использование баз данных: Учебник. М.: Финансы и статистика, 1995. 208 с.
11. Максимов Н. В., Попов И. И. Компьютерные сети. М.: Форум, Инфра-М, 2007. 448 с.
12. Мэйволд Э. Безопасность сетей : практ. пособие. М. : СП ЭКОМ, 2005. 528 с.
13. Мэтьюс М. Грамотная разработка программных приложений. М., 1998.
14. Михайлов А., Мухин А. и др. Концепция информационного обеспечения МП в России. М.: Инфоцентр, 1996. 183 с.
15. Олифер В. Г., Олифер Н. А. Компьютерные сети: Принципы, технологии, протоколы: Учеб. для вузов. 2-е изд. СПб.: Питер, 2003. 863 с.
16. Пятибратов А. П., Гудыно Л. П., Кириченко А. А. Вычислительные системы, сети и телекоммуникации : учебник / под ред. А.П. Пятибратова. М. : Финансы и статистика, 1998. 400 с.
17. Танненбаум Э. Компьютерные сети. СПб.: Питер, 2007. 992 с.
18. Ульман Дж. Основы систем баз данных. М.: Финансы и статистика, 1983. 334 с.
19. Уолтерс Р. Э. SQL Server 2008: ускоренный курс для профессионалов. М.: Вильямс, 2008. 768 с.
20. Щербина С. Web-интеграция: новый взгляд на построение корпоративных информационных систем // Информационные ресурсы России. 2001. N 5. С. 10-11.
21. ГОСТ 34.201-89. Виды, комплектность и обозначение документов при создании автоматизированных систем. URL: cntd.ru (Дата обращения: 23.10.2025).
22. ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы. URL: cntd.ru (Дата обращения: 23.10.2025).
23. Архитектура Клиент-Сервер: что это такое, типы, примеры, особенности. URL: itelon.ru (Дата обращения: 23.10.2025).
24. Клиент-серверная архитектура ИС. URL: studfile.net (Дата обращения: 23.10.2025).
25. Основные особенности и виды архитектур клиент-сервер. URL: ittelo.ru (Дата обращения: 23.10.2025).
26. Критерии выбора СУБД при создании информационных систем. URL: citforum.ru (Дата обращения: 23.10.2025).
27. Критерии выбора субд при создании аис. URL: studfile.net (Дата обращения: 23.10.2025).
28. Системы управления базами данных: Учебное пособие. URL: nvsu.ru (Дата обращения: 23.10.2025).
29. Разработка и экономическое обоснование инвестиционного проекта. URL: core.ac.uk (Дата обращения: 23.10.2025).
30. Чистая приведенная стоимость, NPV. URL: alt-invest.ru (Дата обращения: 23.10.2025).
31. NPV инвестиционного проекта: как рассчитать и зачем это нужно инвестору. URL: investmen.pro (Дата обращения: 23.10.2025).
32. NPV: формула, как рассчитать, пример расчета чистой приведенной стоимости. URL: calltouch.ru (Дата обращения: 23.10.2025).
33. Бизнес-процессы салона красоты — как правильно моделировать, вести и организовывать работу в салоне. URL: salon1c.ru (Дата обращения: 23.10.2025).
34. 7 бизнес-процессов салона красоты, которые надо автоматизировать в первую очередь. URL: sendpulse.com (Дата обращения: 23.10.2025).
35. Информационные системы: Учебное пособие. URL: e-spk.ru (Дата обращения: 23.10.2025).
36. Лекция 1 Информационные системы и их классификации. URL: uor-penza.ru (Дата обращения: 23.10.2025).
37. ER-диаграмма: визуализация связей и сущностей. URL: kurshub.ru (Дата обращения: 23.10.2025).
38. ER-диаграмма: задачи, нотации, правила составления. URL: sales-generator.ru (Дата обращения: 23.10.2025).
39. ER-диаграммы: как создать, примеры построения модели. URL: tbank.ru (Дата обращения: 23.10.2025).
40. Основные понятия ER-моделей данных: методические материалы. URL: infourok.ru (Дата обращения: 23.10.2025).
41. Функциональные и нефункциональные требования (с примерами). URL: visuresolutions.com (Дата обращения: 23.10.2025).
42. Функциональные и нефункциональные требования: ключевые различия. URL: scand.com (Дата обращения: 23.10.2025).
43. Алгоритм описания функциональных требований к системе в формате Use Case. URL: systems.education (Дата обращения: 23.10.2025).