Разработка информационной системы планирования финансовых ресурсов предприятия: Комплексный подход к проектированию, реализации и оценке эффективности

В условиях постоянно меняющегося глобального экономического ландшафта и усиливающейся конкуренции, способность предприятия эффективно управлять своими финансовыми ресурсами становится не просто преимуществом, а жизненной необходимостью. По данным на 2024 год, количество кибератак на финансовый сектор России увеличилось более чем в два раза по сравнению с 2023 годом, за первые 10 месяцев зафиксировано почти 17 000 атак на банки, что подчеркивает критическую важность создания защищенных и надежных информационных систем. Именно поэтому разработка информационной системы планирования финансовых ресурсов предприятия представляет собой актуальную и многогранную задачу, требующую комплексного подхода.

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

Теоретические основы финансового планирования и информационных систем

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

Понятийный аппарат и определения

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

Информационная система (ИС) – это не просто набор компьютеров или программ. Согласно международному стандарту ISO/IEC 2382-1, это система обработки информации, которая функционирует в тесной связке с организационными ресурсами: людьми, техническими средствами и финансовыми потоками, обеспечивая сбор, хранение, обработку и распространение информации. ГОСТ 34.320-96 дополняет это определение, рассматривая ИС как формальную систему, включающую концептуальную схему, информационную базу и информационный процессор, предназначенные для хранения и манипулирования данными. В более широком смысле, как отмечает Федеральный закон «Об информации, информационных технологиях и о защите информации», ИС – это совокупность баз данных и обеспечивающих их обработку информационных технологий и средств. Таким образом, ИС – это сложный, многокомпонентный механизм, призванный автоматизировать и оптимизировать информационные процессы.

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

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

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

Любое предприятие функционирует посредством выполнения бизнес-процессов. ГОСТ Р ИСО 19440-2010 определяет бизнес-процесс как частично упорядоченный набор операций и/или видов деятельности, которые осуществляются для решения одной или нескольких задач предприятия с целью получения желаемого конечного результата. Автоматизация этих процессов с помощью ИС — ключевой путь к повышению эффективности.

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

Теории и методологии финансового планирования

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

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

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

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

• Экономический анализ: Изучение финансовой деятельности предприятия для выявления закономерностей, тенденций и факторов, влияющих на финансовые результаты.
• Нормативный метод: Основан на применении норм и нормативов (например, нормативов запасов, расхода материалов, амортизации) для расчета потребности в финансовых ресурсах.
• Метод многовариантности расчетов: Позволяет оценить несколько сценариев развития событий (оптимистичный, пессимистичный, реалистичный) и выбрать наиболее приемлемый план действий.
• Балансовый метод: Заключается в сопоставлении ресурсов и потребностей в них, обеспечении баланса между поступлениями и расходами.
• Метод коэффициентов: Использование финансовых коэффициентов (например, ликвидности, рентабельности) для оценки текущего состояния и прогнозирования будущих показателей.
• Экономико-математическое моделирование: Применение математических моделей для описания финансовых процессов и поиска оптимальных решений, например, для оптимизации инвестиционного портфеля или структуры капитала.

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

• По хронологическому признаку:
  • Долгосрочное планирование (более 5 лет): Определяет стратегические финансовые цели и пути их достижения.
  • Среднесрочное планирование (1-5 лет): Конкретизирует долгосрочные цели, детализирует бюджеты и инвестиционные программы.
  • Краткосрочное планирование (до 1 года): Включает оперативное бюджетирование, управление денежными потоками и оборотным капиталом.
• По конкретизации целей:
  • Стратегическое планирование: Определяет глобальные финансовые цели предприятия, например, выход на новые рынки, увеличение доли рынка.
  • Тактическое планирование: Направлено на реализацию стратегических целей через конкретные проекты и программы.
  • Оперативное планирование: Ежедневное или еженедельное управление финансовыми ресурсами для обеспечения бесперебойной работы.

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

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

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

Особенности процесса планирования финансовых ресурсов на предприятии

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

Текущее состояние процесса планирования финансовых ресурсов:

В большинстве случаев, процесс планирования финансовых ресурсов на предприятии включает в себя несколько ключевых этапов:

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

Сильные стороны:

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

Слабые стороны и проблемы, требующие автоматизации:

• Разрозненность данных: Информация, необходимая для планирования, часто хранится в различных системах (Excel-таблицы, бухгалтерские программы, CRM), что приводит к дублированию, несогласованности и потере времени на ручной сбор и консолидацию.
• Низкая оперативность: Ручные методы сбора и обработки данных не позволяют оперативно реагировать на изменения, что затрудняет своевременную корректировку планов.
• Высокая трудоемкость: Большое количество ручных операций при составлении бюджетов, их согласовании и анализе приводит к значительным временным и трудовым затратам.
• Риск ошибок: Человеческий фактор при ручном вводе и обработке данных увеличивает вероятность ошибок, которые могут привести к некорректным финансовым решениям.
• Ограниченность аналитических возможностей: Традиционные инструменты не всегда позволяют проводить глубокий многофакторный анализ, моделировать различные сценарии и выявлять скрытые закономерности.
• Сложность контроля и исполнения: Отсутствие единой системы затрудняет контроль за исполнением бюджетов и оперативное выявление отклонений, а также анализ причин их возникновения.
• Отсутствие единой методологии: В крупных предприятиях разные подразделения могут использовать собственные подходы к планированию, что усложняет консолидацию и управление.
• Безопасность данных: Хранение чувствительной финансовой информации в неструктурированных файлах повышает риски несанкционированного доступа и утечек.

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

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

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

Функциональные требования (ЧТО система должна делать):

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

1. Бюджетирование:
   • Создание и управление бюджетами: Возможность создавать различные типы бюджетов (операционные, финансовые, инвестиционные) с гибкой настройкой структуры (по статьям доходов/расходов, центрам ответственности, проектам).
   • Планирование доходов и расходов: Инструменты для детализированного планирования всех статей доходов (продажи, прочие поступления) и расходов (заработная плата, аренда, закупки, налоги).
   • Формирование бюджета движения денежных средств (БДДС): Автоматическое построение БДДС на основе планов доходов и расходов, с учетом графиков платежей и поступлений.
   • Формирование бюджета доходов и расходов (БДР): Формирование БДР для оценки прибыльности операций.
   • Формирование прогнозного баланса: Возможность генерировать прогнозный баланс предприятия.
   • Версионирование бюджетов: Поддержка нескольких версий бюджета (рабочая, утвержденная, пересмотренная) и возможность сравнения.
   • Согласование и утверждение: Механизмы электронного согласования и утверждения бюджетов с возможностью отслеживания статуса и истории изменений.
2. Прогнозирование:
   • Моделирование сценариев: Инструменты для создания различных прогнозных сценариев (оптимистичный, пессимистичный, реалистичный) с изменением ключевых параметров.
   • Прогнозирование финансовых показателей: Возможность прогнозирования доходов, расходов, прибыли, денежных потоков на основе исторических данных и заданных алгоритмов.
   • Использование различных методов прогнозирования: Поддержка статистических методов (например, регрессионный анализ, экспоненциальное сглаживание) и экспертных оценок.
3. Анализ и контроль:
   • Сравнительный анализ «план-факт»: Автоматическое сравнение плановых и фактических показателей с выделением отклонений.
   • Анализ причин отклонений: Инструменты для детализации и анализа факторов, повлиявших на отклонения.
   • Финансовые коэффициенты и индикаторы: Автоматический расчет ключевых финансовых коэффициентов (рентабельность, ликвидность, оборачиваемость) и индикаторов финансового состояния.
   • Формирование отчетов: Генерация настраиваемых аналитических отчетов в различных разрезах (по периодам, подразделениям, проектам, статьям).
   • Дашборды и визуализация данных: Представление ключевых финансовых показателей в виде интерактивных дашбордов для быстрого анализа и принятия решений.
4. Управление денежными потоками:
   • Платежный календарь: Формирование и управление платежным календарем для оптимизации движения денежных средств.
   • Управление ликвидностью: Инструменты для мониторинга и управления текущей ликвидностью предприятия.
5. Интеграция:
   • Интеграция с существующими системами: Возможность обмена данными с бухгалтерскими, складскими, CRM-системами предприятия для автоматического получения фактических данных.
   • Импорт/экспорт данных: Поддержка импорта и экспорта данных в различных форматах (Excel, CSV) для удобства работы.

Нефункциональные требования (КАК хорошо система должна работать):

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

1. Производительность: Система должна обеспечивать высокую скорость обработки данных и генерации отчетов, даже при работе с большими объемами информации и одновременном доступе большого числа пользователей. Время отклика на запросы пользователей не должно превышать 2-3 секунд.
2. Надежность: Система должна быть устойчива к сбоям, обеспечивать сохранность данных и их целостность. Должны быть предусмотрены механизмы резервного копирования и восстановления данных. Время простоя системы не должно превышать 0,1% от общего рабочего времени.
3. Масштабируемость: Система должна быть способна к наращиванию функционала и производительности по мере роста потребностей предприятия, увеличения объемов данных и числа пользователей без существенной переработки архитектуры.
4. Безопасность:
   • Контроль доступа: Гибкая система разграничения прав доступа к данным и функциям на основе ролей пользователей.
   • Защита данных: Шифрование конфиденциальных финансовых данных при хранении и передаче.
   • Аудит действий: Ведение журнала всех операций пользователей для отслеживания изменений и подозрительной активности.
   • Защита от внешних угроз: Меры по предотвращению DDoS-атак, фишинга, внедрения вредоносного ПО.
   • Соответствие стандартам: Соблюдение требований регуляторов по информационной безопасности для финансовых систем (например, СТО БР ИББС-1.0-2014, ГОСТ Р 57580.1-2017).
5. Удобство использования (Эргономика):
   • Интуитивно понятный интерфейс: Простой и логичный интерфейс, не требующий длительного обучения.
   • Дружелюбная навигация: Легкость перемещения по системе и доступа к необходимым функциям.
   • Минимальный ввод данных: Использование значений по умолчанию, выпадающих списков, автозаполнения для сокращения ручного ввода.
   • Система помощи: Наличие контекстной справки и руководства пользователя.
6. Сопровождаемость: Легкость внесения изменений, обновлений и поддержки системы. Код должен быть документирован и соответствовать стандартам кодирования.
7. Совместимость: Возможность работы системы на различных операционных системах и в различных веб-браузерах (если это веб-приложение).

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

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

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

Обзор и выбор методологий разработки ПО

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

Исторический экскурс и основные подходы:

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

• Простота и прозрачность: Четкое разделение этапов, легкость контроля прогресса.
• Подробная документация: Каждый этап сопровождается созданием исчерпывающей документации.
• Идеально для стабильных требований: Хорошо подходит для проектов с четко определенными и неизменяемыми требованиями.

Однако у водопадной модели есть и существенные недостатки:

• Негибкость: Любые изменения требований на поздних стадиях проекта приводят к значительным переделкам и увеличению стоимости.
• Позднее обнаружение ошибок: Ошибки проектирования или требований могут быть обнаружены только на этапах тестирования или внедрения.
• Длительный цикл разработки: Заказчик видит работающий продукт только в самом конце проекта.

В ответ на недостатки водопадной модели, особенно в условиях быстро меняющегося рынка и нечетко сформулированных требований, появились итеративные и инкрементальные методологии, объединенные под общим зонтиком Agile. Agile-подходы (Scrum, Kanban, XP) ставят во главу угла:

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

Преимущества Agile:

• Быстрый вывод продукта на рынок (или его частей): Заказчик получает ценность раньше.
• Высокое качество продукта: Постоянная обратная связь и частые тестирования.
• Повышенная удовлетворенность заказчика: Вовлеченность в процесс и видимый прогресс.

Недостатки Agile:

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

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

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

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

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

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

Применение стандартов в жизненном цикле ИС

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

Роль стандартов в разработке ПО:

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

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

Ключевые стандарты в контексте дипломной работы:

1. SEI SW-CMM (Capability Maturity Model for Software): Разработанная Институтом программной инженерии (SEI) Университета Карнеги-Меллона, эта модель не является жестким стандартом, но представляет собой мощный инструмент для оценки и совершенствования процессов разработки ПО. Она описывает пять уровней зрелости:
   • Начальный (Initial): Процессы непредсказуемы, успех зависит от индивидуальных усилий.
   • Повторяемый (Repeatable): Базовые процессы управления проектами установлены, можно повторять успешные практики.
   • Определенный (Defined): Процессы документированы, стандартизированы и интегрированы в рамках всей организации.
   • Управляемый (Managed): Процессы измеряются и контролируются статистическими методами.
   • Оптимизируемый (Optimizing):): Процессы постоянно совершенствуются.

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

2. ISO 9001 и ISO/IEC 90003:2018:
   • ISO 9001 – это общий стандарт для систем менеджмента качества, применимый к любой организации, включая разработчиков программного обеспечения. Он устанавливает требования к разработке, документированию, внедрению и поддержке системы менеджмента качества.
   • ISO/IEC 90003:2018 – это специализированное руководство, которое предоставляет рекомендации по применению ISO 9001 к процессам разработки, приобретения и поддержки программного обеспечения. Для дипломной работы это означает, что каждый этап жизненного цикла ИС должен быть не просто выполнен, но и спланирован, документирован, контролирован и, при необходимости, скорректирован в соответствии с принципами менеджмента качества.
3. TickITplus: Эта схема сертификации систем качества для программного обеспечения, основанная на ISO 9001, разработанная для предоставления рекомендаций по интерпретации ISO 9001 в контексте разработки ПО. С 2011 года она заменила оригинальную схему TickIT, обеспечивая более процесс-ориентированный подход и интегрируясь с другими важными стандартами, такими как ISO/IEC 27001 (информационная безопасность) и ISO/IEC 20000-1 (управление ИТ-услугами). Использование принципов TickITplus в дипломной работе поможет обеспечить комплексный подход к качеству и управлению проектом.
4. ГОСТ Р ИСО/МЭК 12207—2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»: Этот стандарт регламентирует общую структуру процессов жизненного цикла программных средств, охватывая все этапы от концепции до вывода из эксплуатации. Он служит основой для построения процессов разработки в дипломной работе, обеспечивая полноту и последовательность.
5. ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания»: Один из ключевых российских стандартов, определяющий основные этапы и стадии процесса создания автоматизированных систем. Он будет подробно рассмотрен в разделе, посвященном этапам разработки, и станет методической основой для структурирования проектной части дипломной работы.
6. UML (Unified Modeling Language): Это не стандарт разработки процессов, а унифицированный язык моделирования, который появился в результате стандартизации методов объектно-ориентированного анализа и проектирования. UML — графический язык для описания и визуализации абстрактных моделей, таких как структура базы данных или последовательность выполнения запросов ПО. Его преимущества включают стандартизацию, полноту обозначений для всех сущностей и широкую распространённость в IT, менеджменте и инженерии. UML позволяет описывать систему со всех возможных точек зрения и аспектов её поведения, повышает качество кода, упрощает проектирование и способствует созданию чёткой документации. В рамках дипломной работы UML будет активно использоваться для построения диаграмм, таких как диаграммы вариантов использования, классов, последовательностей, деятельности, что позволит наглядно представить архитектуру, функционал и логику работы будущей ИС.
7. ГОСТ Р 59795-2021 «Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»: Этот стандарт устанавливает требования к содержанию документов, создаваемых на разных этапах жизненного цикла автоматизированных систем, включая решения по составу программных средств, языкам программирования и алгоритмам. Он будет служить руководством при разработке технической документации в дипломной работе.
8. Комплекс стандартов на автоматизированные системы (КСАС) и Единая система программной документации (ЕСПД): Эти комплексы стандартов являются основными в России для разработки документации на программное обеспечение и автоматизированные системы. Они будут использоваться для обеспечения соответствия документации проекта российским требованиям.

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

Проектирование архитектуры и выбор средств реализации

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

Предложенная архитектура ИС: Многозвенная архитектура

Для информационной системы планирования финансовых ресурсов предприятия наиболее оптимальным решением является многозвенная архитектура (N-tier architecture). В отличие от простой клиент-серверной модели (двухзвенной), где клиент напрямую взаимодействует с базой данных, многозвенная архитектура разделяет систему на несколько логических и физических уровней, что значительно повышает ее гибкость, масштабируемость и безопасность.

Как правило, многозвенная архитектура включает в себя как минимум три уровня:

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

Преимущества многозвенной архитектуры:

• Масштабируемость: Каждый уровень можно масштабировать независимо друг от друга. Например, при увеличении числа пользователей можно добавить дополнительные серверы приложений, не затрагивая базу данных.
• Безопасность: Разделение уровней позволяет применять различные механизмы защиты на каждом уровне, ограничивая прямой доступ к базе данных извне.
• Гибкость: Изменения в бизнес-логике или пользовательском интерфейсе могут быть внесены без полного переписывания всей системы.
• Сопровождаемость: Разделение ответственности между уровнями упрощает разработку, тестирование и обслуживание системы.
• Распределение нагрузки: Разделение функционала на разные серверы позволяет более эффективно распределять вычислительную нагрузку.

Обоснование выбора языков программирования, СУБД и других технологических компонентов:

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

1. Языки программирования:
   • Для уровня бизнес-логики и бэкенда:
     • Python (с фреймворками Django/Flask): Отличный выбор для быстрой разработки, обладает богатой экосистемой библиотек для математических расчетов, анализа данных и интеграции. Простота синтаксиса ускоряет процесс написания кода.
     • Java (с фреймворками Spring Boot): Классический выбор для корпоративных систем, обеспечивает высокую производительность, надежность и масштабируемость. Обладает мощными инструментами для построения сложных бизнес-логик.
     • C# (с фреймворком .NET Core): Универсальное решение от Microsoft, подходящее для кроссплатформенной разработки высокопроизводительных приложений.
   • Для уровня представления (фронтенда) веб-приложения:
     • JavaScript (с фреймворками React, Angular, Vue.js): Стандарт для современных интерактивных веб-интерфейсов. Эти фреймворки обеспечивают высокую производительность, модульность и удобство разработки сложных UI.
2. Система управления базами данных (СУБД):
   • PostgreSQL: Мощная, надежная, объектно-реляционная СУБД с открытым исходным кодом. Отличается высокой производительностью, широким набором функций, поддержкой сложных запросов и отличной масштабируемостью. Идеально подходит для хранения структурированных финансовых данных.
   • MySQL: Популярная реляционная СУБД с открытым исходным кодом, хорошо подходит для веб-приложений. Проста в использовании и администрировании.
   • Microsoft SQL Server / Oracle Database: Если предприятие уже использует эти коммерческие СУБД, их выбор может быть обусловлен унификацией инфраструктуры и наличием квалифицированных специалистов.
3. Другие технологические компоненты:
   • Система контроля версий (Git): Необходима для совместной разработки и управления изменениями в коде.
   • Docker/Kubernetes: Для контейнеризации и оркестрации приложений, что упрощает развертывание и масштабирование системы.
   • Nginx/Apache: Веб-серверы для обработки HTTP-запросов.

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

UML (Unified Modeling Language) играет незаменимую роль на этапе проектирования, позволяя визуализировать сложную структуру системы до написания кода.

• Для структуры базы данных: Диаграммы классов (Class Diagrams) в UML могут быть использованы для моделирования сущностей базы данных, их атрибутов и связей. Каждая таблица БД может быть представлена как класс, а ее поля — как атрибуты класса. Это позволяет наглядно представить логическую структуру данных, взаимосвязи между ними и обеспечить согласованность проектирования БД с бизнес-логикой.
• Для последовательности выполнения запросов: Диаграммы последовательности (Sequence Diagrams) или Диаграммы деятельности (Activity Diagrams) в UML позволяют описать динамическое поведение системы.
  • Диаграммы последовательности демонстрируют взаимодействие объектов во времени, показывая порядок вызовов методов и передачу сообщений между компонентами системы (например, как запрос пользователя от клиентского интерфейса проходит через сервер приложений к базе данных и обратно).
  • Диаграммы деятельности могут быть использованы для моделирования бизнес-процессов планирования финансовых ресурсов, показывая последовательность действий, условия перехода и параллельное выполнение операций.

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

Реализация информационной системы и особенности внедрения

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

Этапы разработки и документирования

Разработка информационной системы, согласно ГОСТ 34.601-90, представляет собой последовательность взаимосвязанных стадий, каждая из которых имеет свои цели и результаты. Это обеспечивает системность и управляемость проекта.

Детализация этапов создания ИС согласно ГОСТ 34.601-90:

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

Требования к содержанию документов автоматизированных систем (ГОСТ Р 59795-2021):

ГОСТ Р 59795-2021 устанавливает детальные требования к содержанию различных документов, которые разрабатываются в процессе создания АС. Этот стандарт регламентирует, какие сведения должны быть включены в проектную и рабочую документацию. Например, он требует четкого описания:

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

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

Внедрение и опытно-промышленная эксплуатация

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

Установка и настройка системы:

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

• Развертывание серверных компонентов: Установка операционной системы (если требуется), СУБД, сервера приложений, веб-сервера (если это веб-приложение), настройка сетевых параметров и файловых систем.
• Развертывание клиентских компонентов: Установка клиентских приложений (если это десктопное решение) или настройка доступа к веб-интерфейсу через браузер.
• Настройка безопасности: Конфигурирование брандмауэров, систем обнаружения вторжений, SSL-сертификатов, а также настройка ролей и прав доступа пользователей в самой системе.
• Интеграция с существующими системами: Настройка обмена данными с другими информационными системами предприятия (бухгалтерскими, ERP, CRM) через API или другие механизмы.
• Загрузка начальных данных: Ввод или импорт исторических финансовых данных, справочников, организационной структуры, пользователей и их ролей. Это критически важный шаг, требующий тщательной проверки корректности данных.

Тестирование системы:

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

• Модульное тестирование (Unit Testing): Проверка отдельных компонентов или модулей программы разработчиками.
• Интеграционное тестирование (Integration Testing): Проверка взаимодействия между различными модулями и компонентами системы.
• Системное тестирование (System Testing): Комплексная проверка всей системы на соответствие функциональным и нефункциональным требованиям, включая производительность, безопасность и надежность.
• Приемочное тестирование (Acceptance Testing): Проводится конечными пользователями или заказчиком для подтверждения того, что система соответствует их бизнес-потребностям и готова к использованию. В контексте финансового планирования это может включать проверку корректности расчетов бюджетов, формирования отчетов, работы с различными сценариями.
• Нагрузочное тестирование (Load Testing): Оценка поведения системы под нагрузкой, близкой к реальной, для выявления потенциальных узких мест и обеспечения требуемой производительности.
• Тестирование безопасности (Security Testing): Проверка системы на наличие уязвимостей, устойчивость к хакерским атакам, соблюдение политик безопасности.

Запуск в опытно-промышленную эксплуатацию:

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

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

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

Информационная безопасность и эргономика в системе планирования финансовых ресурсов

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

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

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

Основные типы кибератак и актуальная статистика:

Ситуация с кибератаками на финансовый сектор России в 2024 году вызывает серьезную тревогу. Согласно данным, количество кибератак на российские банки за первые 10 месяцев 2024 года увеличилось более чем в два раза по сравнению с 2023 годом, достигнув почти 17 000 атак. Финансовая отрасль, хотя и занимает третье место по общему числу кибератак, выходит на второе место по количеству высококритичных инцидентов, которых с начала 2024 года зафиксировано более 3000. По данным Банка России, в 2024 году получено более 750 сообщений о компьютерных атаках на финансовые компании.

Ключевыми угрозами, стоящими перед финансовой отраслью в 2024 году, остаются:

• Сетевые атаки, в частности DDoS-атаки: Эти атаки направлены на вывод из строя инфраструктуры или обеспечение недоступности сервисов, парализуя работу финансовых систем. Значительная часть сообщений о компьютерных атаках в 2024 году была связана именно с DDoS.
• Эксплуатация уязвимостей: Хакеры активно ищут и используют «дыры» в программном обеспечении, операционных системах и сетевом оборудовании для получения несанкционированного доступа.
• Вредоносное программное обеспечение (ВПО): Включает в себя широкий спектр угроз:
  • Шифровальщики (ransomware): Блокируют доступ к данным и требуют выкуп.
  • Инструменты удаленного администрирования (RAT): Позволяют хакерам скрытно контролировать скомпрометированные системы.
  • Стиллеры (stealers): Предназначены для кражи учетных данных, платежной информации и других конфиденциальных данных.
  • Ботнеты: Сети зараженных устройств, используемые для проведения масштабных атак.
• Фишинг: Методы социальной инженерии, направленные на выманивание конфиденциальной информации (логины, пароли, данные карт) через поддельные сайты или письма.
• Утечки данных: По данным за 2024 год, из финансовых организаций утекло 410 миллионов строк данных, включая персональные данные пользователей. Это колоссальный объем информации, который может быть использован для мошенничества, шантажа или продажи на черном рынке.

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

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

• Безопасность корпоративных ресурсов и конечных устройств: Защита серверов, рабочих станций, мобильных устройств, используемых сотрудниками.
• Защита чувствительной информации и персональных данных: Реализация механизмов шифрования, маскирования, контроля доступа к финансовым данным и персональным данным пользователей.
• Соответствие требованиям регуляторов: Это не просто «галочка», а обязательное условие. В России это, в частности, стандарты Банка России (СТО БР ИББС-1.0-2014) и национальные стандарты (ГОСТ Р 57580.1-2017), которые устанавливают требования к обеспечению информационной безопасности финансовых организаций. Несоблюдение этих требований может повлечь за собой серьезные штрафы и репутационные потери.
• Предотвращение утечек и выявление внутренних злоупотреблений: Внедрение систем DLP (Data Loss Prevention) для контроля за перемещением конфиденциальной информации и систем SIEM (Security Information and Event Management) для выявления подозрительной активности.
• Обучение персонала: Человеческий фактор остается одним из самых слабых звеньев в цепочке безопасности. Регулярное обучение сотрудников правилам кибергигиены и распознаванию угроз критически важно.

Комплексный подход к ИБ включает:

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

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

Принципы проектирования эргономичного пользовательского интерфейса

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

Что такое эргономичный интерфейс?

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

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

Ключевые принципы создания эргономичного интерфейса:

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

1. Естественность (интуитивность): Интерфейс должен быть интуитивно понятным, чтобы пользователь мог выполнять задачи без предварительного обучения или обращения к справке. Элементы управления должны выглядеть и вести себя так, как ожидают пользователи, исходя из их повседневного опыта. Например, кнопка «Сохранить» должна выглядеть как дискета или иметь соответствующий текст.
2. Непротиворечивость (согласованность): Все элементы интерфейса, действия и терминология должны быть единообразными на протяжении всей системы. Если кнопка «Отчеты» находится в одном месте, она должна быть там же и в других разделах. Если определенный цвет используется для обозначения ошибки, он не должен использоваться для других целей. Это снижает когнитивную нагрузку на пользователя.
3. Неизбыточность (минимальный ввод данных, использование значений по умолчанию): Система должна максимально сокращать объем информации, которую пользователь должен вводить вручную. Это включает:
   • Автозаполнение полей: На основе исторических данных или справочников.
   • Использование выпадающих списков: Для выбора из заранее определенного набора значений.
   • Установка значений по умолчанию: Если есть наиболее вероятный или часто используемый вариант.
   • Минимизация переключений между экранами: Важные функции должны быть доступны в рамках одного или минимального количества экранов.
4. Непосредственный доступ к системе помощи: Пользователь должен иметь возможность получить помощь в любой момент работы с системой, не покидая текущего контекста. Это может быть контекстная справка, всплывающие подсказки, ссылки на полное руководство пользователя или контактные данные службы поддержки.
5. Обратная связь: Система должна постоянно информировать пользователя о статусе его действий – например, показывать индикатор загрузки, сообщение об успешном сохранении данных или об ошибке.
6. Гибкость и эффективность использования: Интерфейс должен быть эффективен как для новичков, так и для опытных пользователей, предлагая быстрые пути выполнения частых операций (горячие клавиши, настраиваемые панели).
7. Управление ошибками: Система должна предотвращать ошибки, где это возможно (например, путем валидации ввода), и предоставлять четкие, понятные сообщения об ошибках с рекомендациями по их устранению.

Стандарты, регулирующие эргономику:

Проектирование эргономичного интерфейса не является исключительно искусством; оно также опирается на научные исследования и стандарты.

• ГОСТ Р ИСО 9241-110-2016 «Эргономика взаимодействия человек-система. Часть 110. Диалоги. Принципы»: Этот стандарт устанавливает принципы для проектирования диалогов между пользователем и системой, направленные на повышение удобства использования и эффективности.
• ГОСТ Р ИСО 9241-129-2014 «Эргономика взаимодействия человек-система. Часть 129. Руководство по индивидуализации программного обеспечения»: Данный стандарт предоставляет рекомендации по адаптации программного обеспечения к индивидуальным потребностям пользователей, что особенно важно для сложных систем, где разные категории пользователей могут иметь разные требования к интерфейсу.

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

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

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

Методики оценки экономической эффективности внедрения ИС

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

1. Сбалансированная система показателей (Balanced Scorecard, BSC, ССП):
   • Сущность: BSC — это стратегическая система управления эффективностью, которая связывает бизнес-стратегию с финансовыми и нефинансовыми показателями, распределенными по четырем перспективам:
     • Финансы: Традиционные финансовые метрики (прибыль, рентабельность, ROI).
     • Клиенты: Удовлетворенность клиентов, лояльность, доля рынка.
     • Внутренние бизнес-процессы: Эффективность и качество операционной деятельности.
     • Обучение и развитие: Инновации, компетенции сотрудников, организационная культура.
   • Применимость: При внедрении ИС планирования финансовых ресурсов, BSC позволяет оценить не только прямую экономию, но и улучшение качества принимаемых решений, повышение скорости обработки данных, рост удовлетворенности финансовых специалистов, а также потенциал для дальнейшего развития и инноваций. Например, ИС может улучшить «Внутренние бизнес-процессы» за счет автоматизации, что в конечном итоге повлияет на «Финансы».
2. Метод совокупного экономического эффекта (Total Economic Impact, TEI):
   • Сущность: Разработанный Forrester Research, метод TEI предлагает всестороннюю оценку проекта внедрения ИС с четырех ключевых позиций:
     • Стоимость (Costs): Все затраты, связанные с проектом (покупка ПО, внедрение, обучение, поддержка).
     • Преимущества (Benefits): Количественные (снижение операционных расходов, увеличение доходов) и качественные (улучшение качества данных, повышение прозрачности) выгоды.
     • Гибкость (Flexibility): Способность системы адаптироваться к изменяющимся условиям бизнеса и рынка, ее потенциал для будущего роста.
     • Риски (Risks): Анализ и учет потенциальных рисков, которые могут повлиять на проект и его результаты.
   • Применимость: TEI позволяет не просто рассчитать ROI, но и учесть «скрытые» преимущества (например, улучшение корпоративного управления благодаря лучшей отчетности) и риски, предоставляя более полную картину ценности проекта.
3. Финансовые методы оценки эффективности инвестиций:

   Эти методы являются краеугольным камнем для количественной оценки проекта и позволяют сравнить инвестиции в ИС с альтернативными вариантами.

   • Коэффициент рентабельности инвестиций (ROI – Return on Investment):
     • Сущность: Классический способ анализа прибыльности инвестиций, показывающий, насколько доходными были вложения.
     • Формула: ROI = ((Доход от вложений - Размер вложений) / Размер вложений) × 100%.
     • Пример: Если внедрение ИС стоило 5 000 000 рублей и принесло доход (экономию, увеличение прибыли) в 6 000 000 рублей, то ROI = ((6 000 000 - 5 000 000) / 5 000 000) × 100% = 20%.
     • Ограничения: Несмотря на простоту, ROI имеет ограничения: он не учитывает временную стоимость денег (инфляцию, дисконтирование) и сложность учета всех факторов, влияющих на прибыльность (например, операционные расходы, производство).
   • Приведенная стоимость (PV – Present Value):
     • Сущность: Стоимость будущих денежных потоков, приведенная к текущему моменту времени с учетом ставки дисконтирования. Позволяет сравнивать инвестиции, генерирующие доходы в разное время.
   • Чистая приведенная стоимость (NPV – Net Present Value):
     • Сущность: Сумма приведенных стоимостей всех денежных потоков (как положительных, так и отрицательных) за весь период проекта, минус начальные инвестиции. Положительное значение NPV указывает на экономическую выгодность проекта.
     • Формула: NPV = Σnt=0 (CFt / (1 + r)t) - IC, где:
       • CF_t — денежный поток в период t (например, годовая экономия или прирост прибыли).
       • r — ставка дисконтирования (отражает альтернативную стоимость капитала и риски).
       • t — номер временного периода.
       • IC — начальные инвестиции в ИС.
     • Пример: Проект требует начальных инвестиций (IC) 5 000 000 рублей. Ожидаемые денежные потоки (CF_t) за 3 года: 2 000 000, 2 500 000, 3 000 000 рублей. Ставка дисконтирования (r) = 10% (0,1).

       NPV = (2 000 000 / (1 + 0,1)1) + (2 500 000 / (1 + 0,1)2) + (3 000 000 / (1 + 0,1)3) - 5 000 000

       NPV ≈ 1 818 181 + 2 066 115 + 2 253 944 - 5 000 000 ≈ 1 138 240 рублей.

       Положительное NPV означает, что проект выгоден.

   • Внутренняя доходность инвестиций (IRR – Internal Rate of Return):
     • Сущность: Ставка дисконтирования, при которой NPV проекта равно нулю. Если IRR выше стоимости капитала предприятия, проект считается привлекательным.
     • Расчет: Требует итерационных методов или финансовых функций в ПО.
   • Период окупаемости инвестиций (PP – Payback Period):
     • Сущность: Время, за которое первоначальные инвестиции окупаются за счет чистых денежных потоков от проекта.
     • Формула для равномерных денежных потоков: PP = Начальные вложения (Ко) / Среднегодовые денежные поступления (CFср).
     • Формула для неравномерных потоков: PP определяется как точка, в которой накопленный чистый доход становится положительным.
     • Пример (равномерные): Начальные вложения 5 000 000 рублей, среднегодовые поступления 2 000 000 рублей. PP = 5 000 000 / 2 000 000 = 2,5 года.
     • Ограничения: Метод не учитывает временную стоимость денег и денежные потоки, генерируемые после точки окупаемости, что может привести к неоптимальным решениям при сравнении проектов.

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

Анализ и управление рисками проекта внедрения ИС

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

Классификация рисков:

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

1. Временные риски: Связаны с соблюдением сроков проекта.
   • Задержка при планировании и утверждении проекта: Длительные процедуры согласования, отсутствие консенсуса.
   • Ошибочное планирование сроков внедрения: Неверная оценка сложности задач, недоучет зависимостей.
   • Неэффективный план внедрения по технологии: Проблемы с интеграцией, непредвиденные технические сложности.
   • Недостаток ресурсов: Нехватка квалифицированных специалистов или оборудования.
2. Финансовые риски: Связаны с бюджетом проекта.
   • Превышение бюджета: Недооценка стоимости ПО, оборудования, работ, обучения.
   • Недостаточное финансирование: Отсутствие своевременного выделения средств.
   • Изменение рыночных цен: Рост стоимости оборудования или лицензий.
3. Технологические риски: Связаны с выбором и реализацией технологий.
   • Несовместимость систем: Проблемы с интеграцией новой ИС с существующей IT-инфраструктурой.
   • Недостаточная производительность: Система не справляется с нагрузкой.
   • Проблемы с безопасностью: Уязвимости в коде или архитектуре.
   • Выбор устаревших или неперспективных технологий: Что затруднит дальнейшее развитие системы.
4. Организационные риски: Связаны с управлением проектом и изменениями в организации.
   • Сопротивление персонала: Нежелание сотрудников осваивать новую систему.
   • Отсутствие квалифицированных кадров: Нехватка обученных пользователей или администраторов.
   • Неэффективное управление проектом: Отсутствие четкого руководства, контроля, коммуникации.
   • Изменение бизнес-процессов: Проблемы с адаптацией существующих бизнес-процессов к новой системе.
5. Юридические риски: Связаны с нормативно-правовыми аспектами.
   • Несоответствие регуляторным требованиям: Нарушение законодательства о защите данных, финансовой отчетности.
   • Лицензионные риски: Проблемы с использованием ПО без соответствующих лицензий.
6. Социальные риски: Связаны с влиянием на сотрудников и корпоративную культуру.
   • Снижение морального духа: Утомление от внедрения, чувство потери контроля.
7. Эксплуатационные риски: Возникают после запуска системы.
   • Ошибки в работе системы: Баги, приводящие к некорректным расчетам или сбоям.
   • Проблемы с поддержкой: Отсутствие оперативной технической поддержки.

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

Методы анализа рисков:

Анализ рисков проекта внедрения информационных систем включает три основных этапа:

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

Метод анализа чувствительности (устойчивости) проекта:

Этот метод позволяет выявить влияние изменений риск-переменных на эффективность проекта. Например, как изменится NPV или ROI проекта внедрения ИС, если:

• Сроки разработки увеличатся на 20%.
• Стоимость лицензий вырастет на 15%.
• Экономия от автоматизации окажется на 10% ниже ожидаемой.

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

Актуальные данные по доле отечественных ERP-систем на российском рынке:

Сложность оценки эффекта от внедрения и сопоставления эффекта с рисками являются причинами, по которым лишь небольшая часть предприятий использует ERP-системы. Однако ситуация меняется. По итогам 2023 года, более 52% российских компаний использовали отечественные ERP-системы. Прогнозируется, что к концу 2024 года отечественные ERP-системы заняли около 60% российского рынка, из которых 80% приходится на решения «1С». К концу 2025 года доля отечественных ERP-систем, по прогнозам, вырастет до 75%. В сегменте крупнейшего бизнеса ERP-системы используют 90% компаний, но российские ERP-решения используют 56% из них. Эти данные свидетельствуют о растущем доверии к отечественным решениям и активном процессе импортозамещения, что создает благоприятную среду для разработки и внедрения собственных информационных систем планирования финансовых ресурсов.

Управление рисками:

После анализа рисков необходимо разработать стратегии управления ими:

• Уклонение (Avoidance): Изменение плана проекта, чтобы исключить риск.
• Передача (Transfer): Передача риска третьей стороне (например, страхование, аутсорсинг).
• Снижение (Mitigation): Разработка мер для уменьшения вероятности или воздействия риска.
• Принятие (Acceptance): Принятие риска, если его воздействие незначительно или затраты на устранение слишком высоки.

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

Заключение

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

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

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

Особое внимание было уделено методологии проектирования и разработки. Мы обосновали выбор гибридного подхода, сочетающего структурированность водопадной модели с гибкостью итеративной разработки, и детально рассмотрели применение важнейших стандартов: от SEI SW-CMM и ISO 9001 до ГОСТ 34.601-90 и UML. Эти стандарты обеспечивают научную обоснованность, качество и управляемость проекта. Предложенная многозвенная архитектура и выбор современных технологических компонентов (языков программирования, СУБД) подчеркивают стремление к созданию эффективного и масштабируемого решения.

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

Одним из ключевых отличий данной работы является глубокий анализ информационной безопасности и эргономики. Мы выявили основные угрозы кибератак на финансовый сектор, подкрепив их актуальной статистикой за 2024 год, и обосновали необходимость применения комплексных мер защиты в соответствии с регуляторными требованиями (СТО БР ИББС-1.0-2014, ГОСТ Р 57580.1-2017). Принципы проектирования эргономичного интерфейса, такие как интуитивность, непротиворечивость и неизбыточность, были рассмотрены с опорой на стандарты ГОСТ Р ИСО 9241, что гарантирует удобство и эффективность использования системы.

Наконец, мы предложили комплексный подход к оценке экономической эффективности и анализу рисков внедрения ИС. Рассмотрены такие методики, как Сбалансированная система показателей (BSC), метод совокупного экономического эффекта (TEI), а также детально представлены финансовые методы – ROI, NPV, IRR и PP, с примерами расчетов. Классификация рисков и методы их анализа и управления, подкрепленные актуальными данными по рынку отечественных ERP-систем, демонстрируют готовность к практическому применению полученных знаний.

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

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

1. Антопольский А.Б. Проблемы классификации информационных ресурсов по критериям информационной безопасности // НТИ. 2007. № 6. С. 125-126.
2. Бочаров Е.П. Интегрированные Корпоративные информационные системы: Принципы построения: лабораторный практикум. М.: Финансы и статистика, 2005. 234 с.
3. Зенкин А.А. Основы когнитивной компьютерной графики. М.: Наука, 2006. 271 с.
4. Казиев В.М. Введение в практическое тестирование. URL: http://www.intuit.ru/department/informatics/practest/ (дата обращения: 20.01.2009).
5. Карпова Т.С. Базы данных: модели, обработка, реализация. СПб.: Питер, 2005. 392 с.
6. Клещев Н.Т., Романов А.А. Проектирование информационных систем. М.: Российская экономическая академия, 2000. 283 с.
7. Кобринский Б.А. К вопросу о формальном отображении образного мышления и интуиции специалиста в слабоструктурированной предметной области // Новости искусственного интеллекта. 2008.
8. Конноли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика. 2-е изд. М.: Вильямс, 2001. 394 с.
9. Кривошеин М. ER: диаграммы сущность-связь. URL: http://mikkri.narod.ru (дата обращения: 03.03.2009).
10. Кузнецов С.Д. Основы современных баз данных. Курск, 2009. 276 с.
11. Леоненков А. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose. М.: Вильямс, 2006. 357 с.
12. Любушин Н.П. Анализ финансово-экономической деятельности предприятия. М.: ЮНИТИ, 2006. 251 с.
13. Хмельницкий С.В., Шарыхин В.В., Каплунова Н.В. Концепция развития информационных ресурсов. СПб.: Европейский университет в Санкт-Петербурге, 2007. 321 с.
14. Хомоненко А.Д., Цыганков В.М., Мальцев В.М. Базы данных: учебник для высших учебных заведений. СПб.: КОРОНА принт, 2004. 437 с.
15. Информационная система. URL: http://www.ict.edu.ru/node/info/2382-1
16. Информационная безопасность для финансовых организаций. URL: https://securityvision.ru/blog/informacionnaya-bezopasnost-dlya-finansovyx-organizacij/
17. Информационная безопасность в финансовых системах: ключевые аспекты и практические советы. URL: https://falcongaze.com/ru/blog/informatsionnaya-bezopasnost-v-finansovykh-sistemakh/
18. СТАНДАРТЫ В ОБЛАСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // КиберЛенинка. URL: https://cyberleninka.ru/article/n/standarty-v-oblasti-razrabotki-programmnogo-obespecheniya
19. Финансовые ресурсы предприятия: состав, формирование. URL: https://academy.alfabank.ru/articles/finansovye-resursy-predpriyatiya-sostav-formirovanie
20. Понятие и состав финансовых ресурсов и капитала предприятия. URL: http://www.finbook.biz/finansy/fpc_1.htm
21. Информационная безопасность финансовых организаций. URL: https://evraas.ru/informacionnaya-bezopasnost-finansovyx-organizaciy
22. Модели финансового планирования. URL: http://vtsconsult.ru/stati/modeli-finansovogo-planirovaniya
23. Существующие методики оценки экономической эффективности внедрения ИС. URL: http://www.iteam.ru/publications/it/section_18/article_3527/
24. Эргономика пользовательских интерфейсов в информационных системах. Учебное пособие. Лабиринт. URL: https://www.labirint.ru/books/689539/
25. Эргономика пользовательского интерфейса АСОИУ, Основные принципы проектирования. URL: https://bstudy.ru/docs/index-286807.html
26. Общая характеристика планирования — лекция по экономике предприятия. Таганрог: ТТИ ЮФУ, 2011. URL: https://stud.ru/lektsiya-po-ekonomike-predpriyatiya-obshchaya-harakteristika-planirovaniya
27. Планирование деятельности предприятия // Яркина Т. В. Основы экономики предприятия: Планирование деятельности предприятия. URL: http://www.aup.ru/books/i001_03/4_02.htm
28. Опубликован проект ГОСТ Р «Защита информации системы с конструктивной информационной безопасностью. Методология разработки». URL: https://rtmtech.ru/news/opublikovan-proekt-gost-r-zashchita-informatsii-sistemy-s-konstruktivnoy-informatsionnoy-bezopasnostyu-metodologiya-razrabotki/
29. ГОСТ 34.601-90 Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. URL: https://stalpartner.ru/gost/gost-34-601-90
30. Финансовые ресурсы предприятия // КиберЛенинка. URL: https://cyberleninka.ru/article/n/finansovye-resursy-predpriyatiya
31. Значение и развитие информационных систем // Молодой ученый. URL: https://moluch.ru/archive/304/68619/
32. Современные подходы к оценке эффективности информационных систем в бизнесе // КубГУ. URL: https://cyberleninka.ru/article/n/sovremennye-podhody-k-otsenke-effektivnosti-informatsionnyh-sistem-v-biznese
33. Методы оценки эффективности информационных систем бухгалтерский учет // Voronezh State University Scientific Journals. URL: https://cyberleninka.ru/article/n/metody-otsenki-effektivnosti-informatsionnyh-sistem-buhgalterskiy-uch
34. Оценка эффективности внедрения информационных систем // КиберЛенинка. URL: https://cyberleninka.ru/article/n/otsenka-effektivnosti-vnedreniya-informatsionnyh-sistem
35. Пользовательский интерфейс с точки зрения эргономики // Наука через призму времени. URL: https://cyberleninka.ru/article/n/polzovatelskiy-interfeys-s-tochki-zreniya-ergonomiki
36. Выбор и анализ рисков при внедрении новых информационных технологий на предприятиях // КиберЛенинка. URL: https://cyberleninka.ru/article/n/vybor-i-analiz-riskov-pri-vnedrenii-novyh-informatsionnyh-tehnologiy-na-predpriyatiyah
37. Этапы и стадии процесса проектирования информационных систем по ГОСТ 34. URL: https://studfile.net/preview/1721021/page:4/
38. Финансовое планирование на предприятии: проблемы и пути оптимизации. Уральский федеральный университет. 2017. URL: https://elar.urfu.ru/bitstream/10995/62159/1/978-5-7996-2228-5_2017_108.pdf
39. Сдача проекта по ГОСТ 34. Этапы разработки ПО от написания ТЗ до ввода в опытно-промышленную эксплуатацию. URL: https://leantech.ru/sdacha-proekta-po-gost-34-etapy-razrabotki-po-ot-napisaniya-tz-do-vvoda-v-opytno-promyshlennuyu-ekspluatatsiyu/
40. Анализ возможных рисков в проекте внедрения информационной системы. Белорусский государственный университет. URL: https://elib.bsu.by/bitstream/123456789/220556/1/%d0%a8%d0%b0%d0%b2%d0%b5%d0%bb%d1%8c_%d0%90%d0%bd%d0%b0%d0%bb%d0%b8%d0%b7%20%d0%b2%d0%be%d0%b7%d0%bc%d0%be%d0%b6%d0%bd%d1%8b%d1%85%20%d1%80%d0%b8%d1%81%d0%ba%d0%be%d0%b2.pdf
41. Анализ рисков проектов внедрения ERP-систем // КиберЛенинка. URL: https://cyberleninka.ru/article/n/analiz-riskov-proektov-vnedreniya-erp-sistem
42. Анализ и систематизация рисков, возникающих при внедрении корпоративных информационных систем в компаниях // Вестник университета. URL: https://cyberleninka.ru/article/n/analiz-i-sistematizatsiya-riskov-voznikayuschih-pri-vnedrenii-korporativnyh-informatsionnyh-sistem-v-kompaniyah
43. ГОСТ Р 59795-2021 Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов. URL: https://docs.cntd.ru/document/1200181559
44. ГОСТ жизненный цикл информационных систем. URL: https://rosgosts.ru/gost-zhiznennyj-tsikl-informatsionnykh-sistem
45. Виды финансового планирования на предприятии // Международный студенческий научный вестник. URL: https://www.scienceforum.ru/2018/article/2018029509
46. Современные методы финансового планирования и прогнозирования на предприятии // КиберЛенинка. URL: https://cyberleninka.ru/article/n/sovremennye-metody-finansovogo-planirovaniya-i-prognozirovaniya-na-predpriyatii
47. ГОСТ 34.320-96 Информационная технология. Комплекс стандартов на автоматизированные системы. Термины и определения. URL: https://docs.cntd.ru/document/901763131