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

В условиях стремительной цифровизации и глобализации, когда динамика рынков и бизнес-среды изменяется с беспрецедентной скоростью, стратегическое управление компанией становится не просто желательным, а критически важным фактором выживания и процветания. Согласно исследованиям 2021 года, только в 16% российских компаний шла активная цифровая трансформация процессов управления. Однако к 2025 году российские организации демонстрируют тенденцию к переходу от догоняющего сценария к модели опережающего развития и технологической независимости, фокусируясь на управлении данными, развитии платформенных решений и технологиях искусственного интеллекта. Этот переход диктует острую необходимость в надежных и адаптивных инструментах поддержки принятия управленческих решений, центральное место среди которых занимают управленческие информационные системы (УИС).

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

Для достижения поставленной цели в работе последовательно решаются следующие задачи:

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

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

1. Теоретические основы и современные концепции управленческих информационных систем

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

В основе любой дискуссии об УИС лежит понимание ключевых терминов:

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

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

• Системы поддержки стратегического управления ориентированы на высшее руководство и предоставляют агрегированную информацию для долгосрочного планирования и выработки стратегии. Примерами могут служить Информационные системы для руководителей (EIS), которые служат инструментом отчетности, обеспечивая быстрый доступ к сводным отчетам со всех уровней и отделов компании.
• Системы управления эффективностью бизнеса (BPM – Business Performance Management) помогают организациям мониторить, анализировать и оптимизировать ключевые показатели деятельности, связывая их со стратегическими целями.
• Системы операционного управления обеспечивают поддержку повседневной деятельности и могут быть разбиты на несколько классов:
  • Системы бухгалтерского учета и системы управленческого учета, которые формируют основу для финансовой отчетности и внутреннего анализа соответственно.
  • Системы планирования и управления ресурсами (ERP-системы), интегрирующие основные бизнес-процессы от производства до финансов.
  • Специализированные системы, предназначенные для конкретных функций или отраслей.
• Системы АСУ ТП (Автоматизированные системы управления технологическими процессами), направленные на автоматизацию и контроль производственных процессов.

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

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

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

В настоящее время стратегическое управление становится все более необходимым и сложным из-за глобализации, цифровизации, инноваций и экологических проблем. Цифровая трансформация процессов управления оказывает неоднородный эффект на стратегии российских компаний: в частности, её влияние на адаптацию бизнес-моделей выражено менее значительно по сравнению с влиянием на операционную эффективность. Несмотря на то, что, согласно исследованию 2021 года, только 16% российских компаний активно занимались цифровой трансформацией процессов управления, к 2025 году наблюдается переход к модели опережающего развития и технологической независимости, сфокусированной на управлении данными, развитии платформенных решений и технологиях искусственного интеллекта. Топ-менеджмент компании должен постоянно отслеживать процесс выполнения стратегии по ключевым показателям и, при необходимости, корректировать стратегические планы или пересматривать цели. Системы стратегического управления для бизнеса не в наименьшей степени выигрывают от внедрения информационных технологий, поскольку одной из важнейших задач высшего руководства является именно выработка стратегии. Аналитические системы Data Mining являются переходным звеном между оперативным и стратегическим уровнями управления, но не обеспечивают полноценного решения задач выработки и анализа стратегии.

Среди инновационных концепций в стратегическом менеджменте под влиянием цифровых технологий выделяются data-driven стратегии. Эти стратегии позволяют принимать обоснованные и точные решения на основе анализа больших данных, оптимизировать использование ресурсов и стимулировать инновации. Внедрение data-driven систем управления в российских компаниях уже продемонстрировало впечатляющие результаты: рост производительности труда и ключевых метрик эффективности бизнеса в среднем на 30–70%, а также увеличение доли рынка на 9–21%. Ключевым фактором эффективности цифровой экосистемы стратегического управления являются динамические способности компании, обеспечивающие непрерывную реконфигурацию ресурсов и компетенций.

Российский рынок систем управления и обработки данных

Рынок систем управления и обработки данных в России, включающий стратегические аналитические системы, после спада в 2022 году, как ожидается, восстановится не раньше конца 2024 года, но затем будет расти быстрее, чем ИТ в целом, благодаря активному импортозамещению. По итогам 2023 года этот рынок оценивался в 67 млрд рублей, а к 2030 году ожидается, что его объем вырастет почти в 3,5 раза, достигнув более 234 млрд рублей.

Процесс импортозамещения на этом рынке идет очень активно: в 2023 году 82% рынка СУБД и инструментов обработки данных в России приходилось на российские компании, в сравнении с 66% в 2022 году. Общий объем российского ИТ-рынка в 2024 году может превысить 3,5 трлн рублей, со среднегодовым темпом роста в 12% до 2030 года. Это создает благоприятные условия для развития отечественных УИС и стимулирует компании к инвестициям в локальные решения, отвечающие требованиям стратегического управления в условиях цифровой экономики.

2. Методологии проектирования и жизненный цикл управленческих информационных систем

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

Жизненный цикл информационных систем (ЖЦ ИС)

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

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

Методологии разработки УИС

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

2.1. Каскадная модель (Waterfall)

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

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

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

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

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

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

Этапы Waterfall:

1. Требования: Все требования собираются и документируются в самом начале проекта.
2. Проектирование: Разрабатывается логическая и физическая архитектура системы.
3. Внедрение: Происходит кодирование и разработка программного обеспечения.
4. Подтверждение: Система проверяется заказчиком на соответствие требованиям.
5. Обслуживание: Поддержка и доработка системы после ввода в эксплуатацию.

2.2. Гибкие методологии (Agile, Scrum, Kanban)

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

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

Принципы Agile-манифеста:

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

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

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

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

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

В России среди подходов в рамках Agile, Scrum остается основной методологией, используемой в российских компаниях, в то время как Kanban демонстрирует стабильный рост популярности. Интересно, что в 2024 году более 55% российских руководителей проектов применяли гибридные методологии, сочетающие элементы Agile и Waterfall. Например, Agile может использоваться для продуктовых команд, разрабатывающих функционал, а Waterfall — для инфраструктурных проектов, требующих строгого контроля и документирования.

2.3. Другие методологии

Помимо Waterfall и Agile, существуют и другие, менее распространенные, но эффективные методологии:

• Rational Unified Process (RUP): Итеративная модель разработки, основанная на спиральной модели ЖЦ, которая базируется на унифицированном языке моделирования (UML). RUP предлагает гибкую структуру, адаптируемую под различные проекты.
• Microsoft Solution Framework (MSF): Итерационная методология, предполагающая использование объектно-ориентированного моделирования и ориентированная на разработку бизнес-приложений.
• Extreme Programming (XP): Методология командной работы, делающая акцент на эффективной коммуникации между заказчиком и исполнителем, разработке с использованием последовательно дорабатываемых прототипов, парном программировании и частых релизах.
• Спиральная модель: Похожа на инкрементную модель, но с акцентом на анализ рисков на каждом витке спирали. Подходит для критически важных бизнес-задач и новых продуктовых линеек, когда требуются исследования и минимизация неопределенности. Этапы включают планирование, анализ рисков, конструирование и оценку результата.
• Rapid Application Development (RAD): Основана на прототипной технологии, где ИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода.

Стандарты проектирования и документации ИС

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

• ГОСТ 34.601-90: Этот государственный стандарт распространяется на автоматизированные системы и устанавливает стадии и этапы их создания, по своей форме является пошаговым планом, соответствующим каскадной модели жизненного цикла. Он определяет последовательные стадии: формирование требований к АС, разработка концепции АС, техническое задание, эскизный проект, технический проект, рабочая документация, ввод в действие, сопровождение. Стандарт допускает исключение стадии «Эскизный проект» и объединение стадий «Технический проект» и «Рабочая документация» в «Технорабочий проект», а также параллельное выполнение некоторых этапов.
• ГОСТ Р 59795-2021: «Информационные технологии (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов», введенный в действие в 2022 году, устанавливает актуальные требования к содержанию основной документации, разрабатываемой при создании АС, обеспечивая её полноту и единообразие.
• ISO/IEC 12207:1995 (ГОСТ Р ИСО/МЭК 12207-2010): Этот международный стандарт (и его российская версия, идентичная ISO/IEC 12207:2008) определяет процессы жизненного цикла программного обеспечения, предоставляя общую структуру для приобретения, поставки, разработки, эксплуатации и сопровождения программных продуктов и услуг. Он не содержит описания конкретных фаз или этапов, а фокусируется на процессах.
• ISO/IEC 15288:2002 (ГОСТ Р ИСО/МЭК 15288-2005): Данный стандарт устанавливает общие рамки для описания процессов жизненного цикла систем, созданных человеком, включая формирование единой структуры для установления и развития связей и сотрудничества между сторонами.
• ISO/IEC/IEEE 16326:2009 (замененный на ISO/IEC/IEEE 16326:2019): Стандарт посвящен управлению проектами в системной и программной инженерии, предлагая руководство для руководителей проектов по успешному завершению проектов, связанных с программными системами.
• ГОСТ Р ИСО/МЭК 20000 (например, ГОСТ Р ИСО/МЭК 20000-1-2021): Серия стандартов для менеджмента ИТ-услуг, определяющая требования к созданию, внедрению, поддержанию и постоянному улучшению системы менеджмента услуг (СМС).
• ГОСТ Р ИСО/МЭК 25001-2017: Идентичный ISO/IEC 25001:2014, этот стандарт устанавливает требования к планированию и управлению деятельностью, связанной с требованиями к качеству и оценкой качества систем и программных продуктов.
• ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011: Определяет способ организации и выражения архитектурных описаний систем, включая архитектурные точки зрения, структуры и языки, используемые в описаниях архитектуры.
• Актуальный стандарт для спецификации требований: ISO/IEC/IEEE 29148:2011: Этот международный стандарт, пришедший на смену IEEE 830-1998, является более актуальным для спецификации требований к программному обеспечению (SRS) и обеспечивает единую трактовку процессов и продуктов для систем и программного обеспечения.

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

3. Анализ бизнес-процессов и формирование требований к УИС

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

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

Моделирование бизнес-процессов (BPM) — это деятельность по представлению процессов предприятия в графическом или ином стандартизированном виде, что позволяет их анализировать, улучшать и, в конечном итоге, автоматизировать. Обычно эту работу выполняют бизнес-аналитики, эксперты по предмету или смешанные команды.

Цели моделирования бизнес-процессов:

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

Внедрение BPM-решений может привести к значительным улучшениям: сокращение цикла сделки на 20–30%, уменьшение времени на выполнение рутинных процессов на 25% и сокращение времени обработки заявок на 40%, а также снижение количества ошибок на 50%. Однако, согласно исследованиям, только 1% компаний имеют достаточный контроль над своими бизнес-процессами для полной реализации финансовых преимуществ от цифровой трансформации. Управленческое решение инвестировать в моделирование бизнес-процессов часто мотивируется необходимостью документирования требований к проекту в области информационных технологий.

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

Этапы анализа бизнес-процессов

Анализ бизнес-процессов — это совокупность методов и приемов для систематического получения информации о текущем состоянии бизнес-процесса, выявления его сильных и слабых сторон, а также поиска путей для его улучшения. Он необходим для оптимизации операций, внедрения новых информационных систем (ERP, CRM), реинжиниринга бизнес-процессов и подготовки к сертификации системы менеджмента качества (например, ISO 9001).

Основные этапы анализа бизнес-процессов:

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

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

Выявление проблем в бизнес-процессах

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

Типичные проблемы в бизнес-процессах:

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

Инструменты выявления проблем:

• SWOT-анализ: Используется для выявления сильных и слабых сторон бизнес-процесса, а также для прогноза его возможных улучшений или ухудшений (возможности и угрозы).
• Метод выявления проблемных моментов: Систематический поиск мест в процессе, где возникают трудности или снижается эффективность.
• Матрица рисков: Оценка вероятности и влияния различных рисков на процесс.
• FMEA (Failure Mode and Effects Analysis): Анализ видов и последствий потенциальных отказов, позволяющий предвидеть проблемы и их влияние.
• Сценарное моделирование: Проигрывание различных сценариев развития событий для выявления потенциальных проблем.
• Анализ потерь: Выявление причин потерь (времени, ресурсов, качества) позволяет понять корни проблем.

Формирование функциональных и нефункциональных требований к УИС

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

3.1. Функциональные требования

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

Примеры функциональных требований:

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

Функциональные требования описываются в use-кейсах (вариантах использования) или пользовательских сценариях/историях и должны быть всегда описаны, поскольку они составляют ядро функциональности продукта.

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

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

Примеры нефункциональных требований:

• Email-уведомление должно быть отправлено не позже чем через 2 часа после события.
• Каждый запрос пользователя должен обрабатываться не более 5 секунд.
• Страница должна загружаться не более 3 секунд при одновременной работе 10 000 пользователей.
• Система должна обеспечивать 99,99% доступности в рабочее время.
• Система должна соответствовать стандартам безопасности данных (например, ГОСТ Р 34.12-2015, ФЗ № 152 «О персональных данных»).

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

Методы сбора и приоритизации требований

Для сбора требований используются различные методы:

• Интервью: Прямые беседы с заинтересованными сторонами (stakeholders).
• Фокус-группы: Обсуждение требований с группами пользователей.
• Списки требований: Составление структурированных перечней.
• Прототипы: Создание интерактивных макетов системы для визуализации и получения обратной связи.
• Сценарии использования (Use Cases): Описание последовательности действий пользователя и системы для достижения определенной цели.

Для приоритизации требований часто применяется метод MoSCoW (Must-have, Should-have, Could-have, Won’t-have), который позволяет разделить требования по степени их критичности.

Процесс анализа требований включает:

1. Сбор требований: Активное общение с клиентами и пользователями.
2. Анализ требований: Выявление неясностей, неполноты, неоднозначности, противоречий.
3. Документирование требований: Формализация требований.

Требования к ИС определяются на разных уровнях:

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

Для документирования требований к программному обеспечению рекомендуется использовать спецификацию требований к программному обеспечению (SRS). Актуальным международным стандартом для SRS является ISO/IEC/IEEE 29148:2011, который пришел на смену IEEE 830-1998 и обеспечивает единую трактовку процессов и продуктов для систем и программного обеспечения.

Инструменты моделирования бизнес-процессов

Для наглядного представления и анализа бизнес-процессов активно используются графические языки и стандарты:

• BPMN (Business Process Model and Notation): Это графический язык для обработки и моделирования бизнес-процессов организации от начала до конца. Он позволяет стандартизировать и визуализировать потоки данных, участников (пулы и дорожки), события, задачи и шлюзы. BPMN-диаграммы могут быть переведены в исполняемый код (BPEL) для автоматизации процессов.
• UML (Unified Modeling Language): Стандарт моделирования, используемый для спецификации, разработки, визуализации и документирования программных систем. Включает в себя различные типы диаграмм, среди которых для моделирования процессов часто используются диаграммы деятельности.
• Другие методы моделирования: блок-схемы, диаграммы потока данных, диаграммы ролевой деятельности (RAD), IDEF.

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

4. Архитектурные решения и технологические платформы для построения УИС

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

Архитектура УИС

Архитектура информационной системы представляет собой фундаментальные решения о её структуре, взаимодействии компонентов, принципах распределения данных и функциональности. В контексте корпоративных информационных систем (КИС) архитектура требует применения современных методологий, таких как TOGAF (The Open Group Architecture Framework) и Zachman Framework.

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

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

В российской практике, помимо глобальных фреймворков, активно применяются различные архитектурные паттерны. Например, многослойная архитектура (часто трехзвенная: представление, бизнес-логика, данные) позволяет разделить ответственность и упростить разработку. Паттерн «порты и адаптеры» (или гексагональная архитектура) помогает отделить бизнес-логику от инфраструктурных деталей, делая систему более гибкой и тестируемой. CQRS-паттерн (Command Query Responsibility Segregation) разделяет операции чтения и записи данных, что может быть полезно для высоконагруженных систем. Однако для слабонагруженных систем использование микросервисной архитектуры может быть неоправданным из-за увеличения сложности разработки, инфраструктуры, DevOps и потенциальных проблем с производительностью.

Информационные системы, основанные на использовании баз данных, обычно функционируют в архитектуре клиент-сервер, где база данных размещается на сервере, обеспечивая совместный доступ. Модульная архитектура — подход к разработке ПО, при котором приложение разбивается на независимые компоненты (модули), каждый из которых выполняет определенную функцию, имеет свою логику и интерфейс для взаимодействия. Её преимущества включают возможность разработки в большой командой, повторное использование кода, усовершенствованную отладку и тестирование, а также лучшую масштабируемость. Модули используются для сохранения неопределённости в ключевых узлах, оставляя больше свободы в дальнейшем проектировании. Общение между front-end (пользовательским интерфейсом) и back-end (серверной частью) часто происходит с помощью REST API, обеспечивающего гибкость и масштабируемость системы.

Технологические платформы для УИС

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

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

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

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

Классификации БД:

• По структуре: иерархические, сетевые, реляционные (БД в виде таблицы), объектно-ориентированные, NoSQL. Большинство современных СУБД — реляционного типа.
• По способу хранения: централизованные, распределённые.

Российский рынок СУБД активно развивается, особенно в условиях импортозамещения. В 2024 году доля СУБД общего назначения на российском рынке составила 48%, а аналитических систем – 32%. При этом ожидается более динамичное развитие сегмента NoSQL СУБД. Объем российского рынка СУБД по итогам 2023 года достиг 67 млрд рублей, а к 2030 году может вырасти до 234 млрд рублей.

Среди популярных российских СУБД выделяются Postgres Pro (лидер по популярности), Arenadata DB, Digital Q.DataBase, Jatoba, Линтер, Базальт.ДБ, Tantor и КВАДРОС. Эти системы активно используются в государственном, банковском и промышленном секторах, а также в критически важных информационных инфраструктурах. Приложения могут быть созданы как непосредственно в среде СУБД, так и вне её, используя специализированные средства доступа к БД.

4.2. Корпоративные системы: ERP, CRM, SCM

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

• ERP (Enterprise Resource Planning): Предназначена для автоматизации и интеграции основных бизнес-процессов, таких как бухгалтерия, управление цепочкой поставок, производство, управление персоналом. Цель ERP — создание единой базы данных и унифицированного информационного пространства для всего бизнеса. Подходит для среднего и крупного бизнеса. На российском рынке среди ERP-систем лидирующие позиции занимает 1С:ERP, а также широко используются Галактика ERP и ПАРУС.
• CRM (Customer Relationship Management): Предназначена для управления взаимоотношениями с клиентами, охватывая маркетинг, продажи и обслуживание. Её цель — улучшение взаимоотношений с клиентами и увеличение продаж. Больше подходит для торговых и сервисных бизнесов с большими отделами продаж. Среди популярных CRM-систем в России выделяются Мегаплан, Битрикс24 и RetailCRM.
• SCM (Supply Chain Management): Системы управления цепочками поставок, оптимизирующие процессы от закупки сырья до доставки готовой продукции.

Возможно совместное использование и интеграция ERP и CRM систем для создания более полного и эффективного информационного контура предприятия.

4.3. Облачные решения

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

Преимущества облачных решений:

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

Недостатки облачных решений:

• Зависимость от интернета: Постоянное высокоскоростное подключение.
• Необходимость новых навыков: Сотрудникам могут потребоваться новые компетенции для работы с облачными платформами.
• Риски безопасности: Несмотря на усилия провайдеров, риски потери данных, несанкционированного доступа и сбоев сохраняются. В 2024 году 45% всех кибератак в России были направлены на облачные системы, особенно в госсекторе и банках. Сохраняется недоверие со стороны части организаций (31% промышленных предприятий не доверяют публичным облакам для критичных систем).
• Рост цен на облачные услуги: Из-за увеличения стоимости оборудования и дефицита кадров.

Для обеспечения безопасности данных в России требуется размещение дата-центров провайдера на территории РФ, а также соответствие российским криптографическим стандартам (например, ГОСТ Р 34.12-2015, ГОСТ Р 34.11-2012) и регуляторным актам (Приказы ФСТЭК № 17 и № 21, ФЗ № 152 «О персональных данных», ГОСТ Р 57580.1-2017 для финансовых операций).

Виды облачных услуг:

• IaaS (Infrastructure as a Service): Инфраструктура как услуга (виртуальные машины, сети, хранилища).
• PaaS (Platform as a Service): Платформа как услуга (среды для разработки и развертывания приложений).
• SaaS (Software as a Service): Программное обеспечение как услуга (готовые приложения, доступные через интернет).

Российский рынок облачных инфраструктурных сервисов (IaaS и PaaS) в 2023 году вырос на 34% до 121,5 млрд рублей, а в 2024 году ожидается рост на 36,3% до 165,6 млрд рублей. Основными драйверами роста являются импортозамещение, цифровизация и высокий спрос на инфраструктуру для искусственного интеллекта. Cloud.ru и Yandex Cloud являются лидерами рынка, причем Cloud.ru занимает 24,7% рынка IaaS и 45,6% рынка PaaS по итогам 2024 года. Доля SaaS на российском рынке публичных облаков в 2024 году составила 66%. Примеры провайдеров: Amazon Web Services (AWS), Google Cloud, Microsoft Azure, Yandex Cloud, SberCloud, VK Cloud.

Критерии выбора технологических платформ

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

Для ERP/CRM систем:

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

Для облачных решений:

• Цели бизнеса: Совместимость с общей стратегией цифровизации.
• Безопасность: Соответствие нормативным требованиям и стандартам защиты данных.
• Обслуживание и поддержка: Качество SLA (Service Level Agreement) и доступность технической поддержки.
• Стоимость: Модель ценообразования и прозрачность затрат.
• Функциональность и опыт сотрудников: Доступность нужных сервисов и готовность персонала к работе с облаком.

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

5. Эффективное внедрение УИС: управление изменениями, обучение и миграция данных

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

Этапы и условия эффективного внедрения УИС

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

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

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

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

Обучение персонала

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

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

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

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

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

Миграция данных

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

Разновидности данных для миграции:

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

Этапы миграции данных в проектах внедрения КИС обычно включают:

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

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

Управление изменениями

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

Цель управления изменениями:

• Повышение доступности ИТ-услуг.
• Минимизация проблем от неудачн��х изменений, приводящих к сбоям.

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

Методология ITIL (Information Technology Infrastructure Library) предлагает комплексный подход к управлению изменениями. Она выделяет несколько типов изменений:

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

Этапы процесса управления изменениями в ИТ:

1. Идентификация и документирование запросов: Сбор всех предложений по изменениям.
2. Оценка и планирование: Анализ потенциальных последствий, рисков, ресурсов.
3. Утверждение: Согласование с Комитетом по изменениям (CAB) или уполномоченным органом.
4. Реализация: Выполнение изменения.
5. Обзор и завершение: Анализ успешности изменения и его документирование.

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

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

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

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

Основные подходы к оценке эффективности ИС:

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

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

Финансовые показатели и методы

Финансовые методы оценки экономической эффективности ИТ-проектов основываются на принципах дисконтирования и учитывают временную стоимость денег.

6.1. Совокупная стоимость владения (TCO — Total Cost of Ownership)

Метод TCO предназначен для измерения совокупных затрат на ИТ-систему на протяжении всего её жизненного цикла. Он включает как прямые (капитальные затраты на приобретение оборудования и ПО, расходы на управление, выполнение работ, техподдержку, обучение, связь, командировочные), так и косвенные затраты (например, потери от простоя системы или снижение производительности из-за сбоев). Важно понимать, что TCO не является полноценным методом оценки эффективности, так как измеряет только затраты и не учитывает выгоды.

6.2. Возврат на инвестиции (ROI — Return on Investment)

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

ROI = (Прибыль от проекта - Стоимость проекта) / Стоимость проекта * 100%

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

6.3. Другие финансовые методы

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

  ARR = Среднегодовая прибыль / Средняя величина инвестиций * 100%

• Индекс рентабельности инвестиций (Profitability Index, PI): Показатель отношения приведенной стоимости будущих денежных потоков от инвестиционного проекта к сумме первоначальных инвестиций. Проект считается привлекательным, если PI ≥ 1.

  PI = Σ PV(CFt) / Σ PV(It)

  где PV(CF_t) — приведенная стоимость всех положительных денежных потоков;
  PV(I_t) — приведенная стоимость всех отрицательных денежных потоков (включая первоначальные инвестиции).

Нефинансовые показатели и методы (результативность)

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

6.4. Ключевые показатели эффективности (KPI — Key Performance Indicators)

KPI — это количественные параметры продуктивности, измеряющие различные аспекты процесса разработки и работы команды. Они применяются для измерения успеха и определения степени достижения поставленных целей компании, помогают управлять общим прогрессом и оперативно вносить корректировки. Выбор KPI должен основываться на бизнес-целях, ключевых факторах успеха и измеримости метрик (SMART-критерии: Specific, Measurable, Achievable, Relevant, Time-bound).

Примеры KPI для ИТ-проектов и систем:

• Процент проектов, выполненных в срок, в рамках бюджета и в соответствии со спецификацией.
• Среднее время обработки проблемы (MTTR — Mean Time To Resolution).
• Окупаемость инвестиций в ИТ.
• Расходы на ИТ (бюджет и фактические траты).
• Среднее время безотказной работы (MTBF — Mean Time Between Failures).
• Целевая точка восстановления (RPO — Recovery Point Objective) и целевое время восстановления (RTO — Recovery Time Objective).
• Время простоя и время работы системы.

Дополнительные бизнес-ориентированные KPI для оценки внедрения УИС:

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

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

6.5. Сбалансированная система показателей (Balanced Scorecard, BSC)

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

BSC включает четыре ключевые перспективы:

1. Финансовая перспектива: Каким мы должны быть для наших акционеров, чтобы добиться финансового успеха? (Например, ROI, NPV, TCO, расходы на ИТ в % от общих расходов).
2. Клиентская перспектива: Какими мы должны быть для наших клиентов, чтобы реализовать наше видение? (Например, удовлетворенность клиентов, индекс удержания клиентов, опыт внутренних и внешних клиентов).
3. Перспектива внутренних бизнес-процессов: Что мы должны делать особенно хорошо, чтобы удовлетворять наших клиентов и акционеров? (Например, предотвращение проблем, оптимизация процессов, время обработки запросов).
4. Перспектива обучения и развития: Как мы должны поддерживать способность меняться и совершенствоваться, чтобы реализовать наше видение? (Например, обучение персонала, поддержание систем, уровень инноваций).

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

Кейс-стади (Case Study) как метод оценки

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

Кейс-стади помогает:

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

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

7. Риски разработки и внедрения УИС и стратегии их минимизации

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

Риски можно классифицировать по источнику возникновения:

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

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

Типичные риски при разработке и внедрении УИС/ИТ-проектов

7.1. Организационные риски

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

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

7.2. Риски, связанные с требованиями и планированием

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

• Разрастание объема (Scope Creep): Бесконтрольное увеличение объема работ по проекту из-за неправильной постановки исходных целей и задач. По данным PMI, 47-52% проектов сталкиваются с расширением объема работ, что приводит к значительным задержкам и потере до $97 млн на каждый $1 млрд инвестиций из-за плохого управления объемом.
• Отсутствие четких целей и задач на старте проекта.
• Неправильно рассчитанный бюджет: По данным оператора ИТ-решений «Обит» за 2025 год, 61% российских компаний недооценивают полную стоимость владения ИТ-решением, что является одной из ключевых причин провала проектов.
• Ошибки календарного планирования.
• Изменение требований Заказчика без адекватной процедуры управления изменениями.
• Непрочное целеполагание, нереализованные ожидания заказчика.
• Отсутствие ясности в определении функционала.

7.3. Технические риски

Связаны с выбором технологий, производительностью и надежностью системы:

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

7.4. Риски, связанные с данными

Эти риски касаются информации, с которой работает УИС:

• Проблемы с передачей данных (неполнота, некорректность).
• Риск утраты/искажения информации.
• Риск утечки информации (нарушение конфиденциальности).

7.5. Риски, связанные с персоналом и использованием

Относятся к взаимодействию сотрудников с новой системой:

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

7.6. Внешние риски

Факторы, находящиеся вне прямого контроля компании:

• Рыночная волатильность, геополитическая турбулентность, киберкриминал.
• Неисполнение обязательств подрядчиком.
• Рост ИТ-сбоев: В 2024 году количество ИТ-сбоев в российских организациях выросло на 22% по сравнению с 2023 годом, составив 7,2% от общего числа инцидентов в мире.
• Регуляторные изменения: Существует внешний риск, связанный с возможным повышением НДС (до 22%) и страховых взносов (на 7,4%) для ИТ-компаний с 2026 года, что, по мнению отраслевых ассоциаций, может привести к росту цен на ПО на 30-35% и значительно замедлить темпы цифровизации.

Стратегии минимизации рисков и управление ими

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

Этапы управления рисками:

1. Идентификация рисков: Определение рисков, способных повлиять на проект. Используются различные методы: анализ проектной документации, встречи с заинтересованными сторонами и экспертами, контрольные списки, мозговой штурм, SWOT-анализ.
2. Оценка рисков: Определение вероятности возникновения риска и степени его потенциального воздействия. Может быть качественной (оценка по степени возникновения, например, высокая/средняя/низкая) и количественной (оценка в денежном выражении). После оценки риски приоритизируются: в проектном менеджменте часто рекомендуется управлять не более чем 7-10 наиболее приоритетными рисками одновременно.
3. Планирование реагирования на риски (стратегии снижения): Разработка конкретных мер для каждого выявленного риска.

7.7. Стратегии реагирования на риски

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

4. Мониторинг и контроль рисков: Постоянное отслеживание текущих и новых угроз, корректировка планов реагирования в случае изменения ситуации.

Общие рекомендации по минимизации рисков:

• Регулярный пересмотр и корректировка стратегий управления рисками для повышения их эффективности.
• Применение стандартов управления проектами (например, PMBOK) для структурирования процесса.
• Детальный предварительный анализ и проработанный план для старта проекта.
• Вовлечение всех заинтересованных сторон: Обеспечение согласованности и понимания целей проекта.
• Пропаганда изменений: Документальная фиксация изменений в бизнес-процессах, назначение KPI ответственным за внедрение.
• Внедрение Agile-подхода: Может повысить эффективность управления, способствуя итеративной разработке, постоянному взаимодействию, раннему выявлению рисков.
• Использование систем управления проектами и тайм-трекеров для контроля работы.
• Системы мониторинга качества данных: Выявление дубликатов, стандартизация и консолидация данных.
• Развитие культуры осознания рисков в организации.
• Учет тонкостей внутренней инфраструктуры заказчика, решение вопросов с серверным оборудованием, планирование интеграции.
• Бюджет на риски: Рекомендуется закладывать бюджет на риски проекта, при этом стоит учитывать, что затраты на доработки и исправление ошибок в случае неудачной реализации могут достигать 10–30% от общего бюджета, а перезапуск проекта может потребовать вложений, сопоставимых или даже превышающих первоначальный бюджет.

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

Заключение

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

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

Детально изучены методологии проектирования и жизненный цикл информационных систем, от классической каскадной модели до гибких подходов Agile, Scrum и Kanban, а также гибридных моделей, активно применяемых в России. Особое внимание уделено актуальным национальным и международным стандартам, таким как ГОСТ Р 59795-2021 и ISO/IEC/IEEE 29148:2011, что обеспечивает методологическую строгость и практическую релевантность изложенного материала.

Мы погрузились в процесс анализа бизнес-процессов, выявления проблем и формирования функциональных и нефункциональных требований к УИС, подчеркнув значимость инструментов моделирования, таких как BPMN и UML, для создания четкого и однозначного технического задания. Обзор архитектурных решений, включая современные паттерны, и технологических платформ (СУБД, ERP/CRM, облачные решения) с учетом специфики российского рынка и отечественных лидеров, позволил сформировать полное представление о технологическом фундаменте УИС.

Критически важные аспекты эффективного внедрения УИС, такие как обучение персонала (с учетом персонализированных подходов и готовности россиян к IT-обучению), миграция данных и управление изменениями (на основе методологии ITIL), были рассмотрены с точки зрения минимизации рисков и повышения адаптивности организации. Наконец, мы проанализировали комплекс методов оценки экономической эффективности и результативности внедрения УИС, включая финансовые показатели (TCO, ROI, NPV, IRR, ARR, PI) и нефинансовые метрики (KPI, Balanced Scorecard), а также роль кейс-стади как инструмента качественного анализа.

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

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

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

Рекомендации для будущих исследователей и практиков:

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

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

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

1. Афанасьев, В.Г. Человек в управлении обществом. – М., 2007. – 382 с.
2. Гайдамакин, Н.А. Автоматизированные информационные системы, базы и банки данных. – М.: Гелиос, 2002.
3. Дик, В.В. Методология формирования решений в экономических системах и инструментальные среды их поддержки. – М.: Финансы и статистика, 2001.
4. Семакин, И.Г. Информационные системы и модели. – М.: ЛБЗ, 2005.
5. Синявский, Н.Г. Оценка бизнеса: гипотезы, инструментарий, практические решения в различных областях деятельности. – М.: Финансы и статистика, 2004.
6. Щербина, С. Web-интеграция: новый взгляд на построение корпоративных информационных систем // Информационные ресурсы России. – 2001. – № 5. – С.10-11.
7. Системы управления, УИС и ПО. Классификация Управленческих Информационных Систем (часть 2) // Бюро Бизнес Инжиниринга. – URL: https://www.business-engineering.ru/management/management-systems-mis-and-software-classification-of-management-information-systems-part-2.html (дата обращения: 23.10.2025).
8. Архитектура корпоративных информационных систем // Открытые системы. – 2000. – № 1. – URL: https://www.osp.ru/os/2000/01/174984.htm (дата обращения: 23.10.2025).
9. АРХИТЕКТУРА КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ // Северо-Кавказская государственная академия. – URL: https://skgai.ru/assets/files/elib/umk-mag/umk_mag_141_08.04.02_arch_kis.pdf (дата обращения: 23.10.2025).
10. Абдуллина, Г.Б. БАЗЫ ДАННЫХ В ИНФОРМАЦИОННЫХ СИСТЕМАХ: учебник. – Алматы: АУЭС, 2019. – URL: https://www.aues.kz/images/books/2019/abdullina-bazy-dannyh-v-informacionnyh-sistemah-uchebnik.pdf (дата обращения: 23.10.2025).
11. Архитектура информационной системы: что это такое, зачем в этом разбираться заказчику и примеры подходов // Лонг Кэт. – URL: https://longcat.ru/blog/architektura-informacionnoj-sistemy (дата обращения: 23.10.2025).
12. Корпоративные информационные системы в архитектуре предприятия // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/korporativnye-informatsionnye-sistemy-v-arhitekture-predpriyatiya (дата обращения: 23.10.2025).
13. Модульная архитектура как особенность построения современных информационно-вычислительных систем технология интеграции модулей в общую систему // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/modulnaya-arhitektura-kak-osobennost-postroeniya-sovremennyh-informatsionno-vychislitelnyh-sistem-tehnologiya-integratsii-moduley-v (дата обращения: 23.10.2025).
14. Критерии и ошибки при выборе ERP и CRM системы // Founder.ua. – URL: https://founder.ua/ru/kriterii-i-oshibki-pri-vybore-erp-i-crm-sistemy/ (дата обращения: 23.10.2025).
15. Плюсы и минусы облачных технологий // Cloudseller. – URL: https://clouds.ru/blog/plyusy-i-minusy-oblachnykh-tekhnologiy/ (дата обращения: 23.10.2025).
16. Выбираем систему ERP для бизнеса – 9 основных критериев // Neiros. – URL: https://neiros.ru/blog/kak-vybrat-erp-sistemu-9-osnovnykh-kriteriev/ (дата обращения: 23.10.2025).
17. Базы данных. Общие сведения // ЯКласс. – URL: https://www.yaklass.ru/p/informatika/9-klass/teoreticheskie-osnovy-informatiki-13354/bazy-dannykh-obschie-svedeniia-13355/re-57f92027-148c-4f81-b586-7a1a095ddf79 (дата обращения: 23.10.2025).
18. Локальные vs облачные решения: Понимание преимуществ и недостатков // Cloudfresh. – URL: https://cloudfresh.com/ru/blog/on-premise-vs-cloud-solutions/ (дата обращения: 23.10.2025).
19. Облака и облачные сервисы: определение, виды, плюсы и минусы // vc.ru. – URL: https://vc.ru/cloud/708681-oblaka-i-oblachnye-servisy-opredelenie-vidy-plyusy-i-minusy (дата обращения: 23.10.2025).
20. Выбор ERP-системы. Критерии и этапы // erp-online.ru. – URL: https://erp-online.ru/articles/vybor-erp-sistemy.html (дата обращения: 23.10.2025).
21. БАЗЫ ДАННЫХ И СИСТЕМЫ ДЛЯ ИХ УПРАВЛЕНИЯ // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/bazy-dannyh-i-sistemy-dlya-ih-upravleniya (дата обращения: 23.10.2025).
22. Система управления базами данных // Википедия. – URL: https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F_%D0%B1%D0%B0%D0%B7%D0%B0%D0%BC%D0%B8_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 23.10.2025).
23. Базы данных и системы управления базами данных // it-academy.by. – URL: https://www.it-academy.by/upload/iblock/121/121c080087c53d489e2c66b962363aa6.pdf (дата обращения: 23.10.2025).
24. Облачные сервисы: что это такое, какими они бывают и кому полезны // Skillbox. – URL: https://skillbox.ru/media/code/chto-takoe-oblachnye-servisy/ (дата обращения: 23.10.2025).
25. Облачные сервисы — что это такое, виды, достоинства и недостатки технологий // Cleverence. – URL: https://cleverence.ru/blog/oblachnye-servisy-chto-eto-takoe-vidy-dostoinstva-i-nedostatki-tekhnologiy/ (дата обращения: 23.10.2025).
26. ERP или CRM. Полный список отличий для правильного выбора // SoftInform. – URL: https://softinform.com.ua/blog/erp-ili-crm-polnyj-spisok-otlichij-dlya-pravilnogo-vybora/ (дата обращения: 23.10.2025).
27. How to choose an ERP system? // Firmao. – URL: https://firmao.io/en/how-to-choose-an-erp-system/ (дата обращения: 23.10.2025).
28. Особенности реализации цифровой трансформации в уголовно-исполнительной системе на современном этапе ее развития // Издательская группа ЮРИСТ. – 2023. – URL: https://elibrary.ru/item.asp?id=54418659 (дата обращения: 23.10.2025).
29. Информационные системы и технологии, используемые в управлении УИС, как средство повышения его эффективности // Elibrary. – 2022. – URL: https://elibrary.ru/item.asp?id=48421356 (дата обращения: 23.10.2025).
30. Правильный подход к модульной архитектуре // Habr. – 2024. – URL: https://habr.com/ru/articles/803125/ (дата обращения: 23.10.2025).
31. Модульная архитектура: что такое, преимущества // Библиотека программиста. – 2023. – URL: https://proglib.io/p/modulnaya-arhitektura-chto-takoe-preimushchestva-2023-04-04 (дата обращения: 23.10.2025).
32. Сбор и анализ бизнес-требований к IT решениям // IT Экспертиза и Аудит. – URL: https://idelync.ru/services/it-audit/business-requirements-collection/ (дата обращения: 23.10.2025).
33. Омниканальная система для управления коммуникациями // UIS. – URL: https://uiscom.ru/ (дата обращения: 23.10.2025).
34. Стандарты проектирования ис // elibrary.ru. – 2014. – URL: https://www.elibrary.ru/item.asp?id=23533261 (дата обращения: 23.10.2025).
35. Стандарты по вопросам проектирования, разработки, документирования и внедрения ИС // Studref.com. – URL: https://studref.com/391035/informatika/standarty_voprosam_proektirovaniya_razrabotki_dokumentirovaniya_vnedreniya (дата обращения: 23.10.2025).
36. Жизненный цикл информационной системы // inf.e-course.com.ua. – URL: https://inf.e-course.com.ua/glava_3_etapy_postroeniya_informacionnoj_sistemy/zhiznennyj_cikl_informacionnoj_sistemy.html (дата обращения: 23.10.2025).
37. Сравнение методологий разработок Waterfall и Agile // Migra Software. – URL: https://migrasoft.ru/sravnenie-metodologij-razrabotok-waterfall-i-agile/ (дата обращения: 23.10.2025).
38. Стандарты // Школа системного анализа. – URL: https://system-education.ru/standards (дата обращения: 23.10.2025).
39. ГОСТ Р ИСО/МЭК 25045-2015 Информационные технологии (ИТ). Системная и программная инженерия. Требования и оценка качества систем и программного обеспечения (SQuaRE). Модуль оценки восстанавливаемости. – Введ. 2015-12-01. – URL: https://docs.cntd.ru/document/1200120108 (дата обращения: 23.10.2025).
40. Waterfall vs Agile: навигация по методологиям разработки программного обеспечения // Cleverics. – URL: https://cleverics.ru/digital-enterprise/waterfall-vs-agile-navigaciya-po-metodologiyam-razrabotki-programmnogo-obespecheniya/ (дата обращения: 23.10.2025).
41. Agile и Waterfall: методологии разработки ПО // 66 Бит. – URL: https://66bit.ru/blog/agile-i-waterfall-metodologii-razrabotki-po/ (дата обращения: 23.10.2025).
42. УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ИНФОРМАЦИОННЫХ СИСТЕМ // Электронный научный архив УрФУ. – 2022. – URL: https://elar.urfu.ru/bitstream/10995/107076/1/978-5-7996-3392-1_2022_01.pdf (дата обращения: 23.10.2025).
43. Waterfall или Agile: сравнение методологий // Управляем предприятием. – URL: https://www.up-pro.ru/library/strategy/dev_method/waterfall-vs-agile.html (дата обращения: 23.10.2025).
44. Лекция 2. Жизненный цикл информационных систем // vuzlit.ru. – URL: https://vuzlit.ru/81414/lekciya_zhiznennyy_cikl_informacionnyh_sistem (дата обращения: 23.10.2025).
45. Сравнение методологий Waterfall и Agile. Отличие Scrum и Kanban // Дмитрий Моск. – URL: https://dmitrymosk.ru/sravnenie-metodologij-waterfall-i-agile-otlichie-scrum-i-kanban/ (дата обращения: 23.10.2025).
46. Ещё раз про семь основных методологий разработки // Habr. – 2016. – URL: https://habr.com/ru/articles/271169/ (дата обращения: 23.10.2025).
47. СОВРЕМЕННЫЕ МЕТОДИКИ РАЗРАБОТКИ ИНФОРМАЦИОННЫХ СИСТЕМ // elibrary.ru. – 2015. – URL: https://www.elibrary.ru/item.asp?id=25576137 (дата обращения: 23.10.2025).
48. Применение методов моделирования для оптимизации бизнес-процессов в информационных системах // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/primenenie-metodov-modelirovaniya-dlya-optimizatsii-biznes-protsessov-v-informatsionnyh-sistemah (дата обращения: 23.10.2025).
49. Моделирование бизнес-процессов // Википедия. – URL: https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B8%D0%B7%D0%BD%D0%B5%D1%81-%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D0%B2 (дата обращения: 23.10.2025).
50. Функциональные и нефункциональные требования: ключевые различия // SCAND. – URL: https://scand.com/ru/company/blog/functional-vs-non-functional-requirements/ (дата обращения: 23.10.2025).
51. Лекция 9. Моделирование бизнес-процессов // vuzlit.ru. – URL: https://vuzlit.ru/1523428/lekciya_modelirovanie_biznes_processov (дата обращения: 23.10.2025).
52. Моделирование бизнес-процессов: методы оптимизации // Productstar. – URL: https://productstar.ru/blog/business-process-modeling (дата обращения: 23.10.2025).
53. Моделирование бизнес-процессов: метод оптимизации работы компании // compass.team. – URL: https://compass.team/blog/modelirovanie-biznes-processov (дата обращения: 23.10.2025).
54. Как выявить проблемы в бизнес-процессах и что с ними делать? // up-pro.ru. – URL: https://www.up-pro.ru/library/management/problem/kak-vyyavit-problemy.html (дата обращения: 23.10.2025).
55. Анализ бизнес-процессов: методы, примеры и эффективность для компании // bpm.directum.ru. – URL: https://bpm.directum.ru/blog/analiz-biznes-protsessov (дата обращения: 23.10.2025).
56. Анализ бизнес-процессов: этапы и инструменты // TEAMLY. – URL: https://teamly.com/blog/analiz-biznes-protsessov-etapy-i-instrumenty/ (дата обращения: 23.10.2025).
57. Краткое описание BPMN с примерами // Кинзябулатов Рамиль. – URL: https://kinzyabulatov.ru/bpmn-osnovnye-ponyatiya/ (дата обращения: 23.10.2025).
58. Бизнес-процесс на ладони: простые методы анализа и оптимизации // Business Studio. – URL: https://www.businessstudio.ru/articles/repin/articles/process_analysis_methods/ (дата обращения: 23.10.2025).
59. Методы анализа требований // Logrocon. – URL: https://logrocon.ru/blog/metody-analiza-trebovanij/ (дата обращения: 23.10.2025).
60. Анализ бизнес-процессов: этапы и инструменты // SILA Union. – URL: https://silabpm.com/blog/analiz-biznes-processov-etapy-i-instrumenty/ (дата обращения: 23.10.2025).
61. Функциональные и нефункциональные требования (с примерами) // Visure Solutions. – URL: https://visuresolutions.com/ru/blog/functional-and-non-functional-requirements/ (дата обращения: 23.10.2025).
62. Анализ требований // Википедия. – URL: https://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B0%D0%BB%D0%B8%D0%B7_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B9 (дата обращения: 23.10.2025).
63. АНАЛИЗ ТРЕБОВАНИЙ К ИНФОРМАЦИОННЫМ СИСТЕМАМ // elibrary.ru. – 2017. – URL: https://www.elibrary.ru/item.asp?id=30559648 (дата обращения: 23.10.2025).
64. Краткое описание нотации BPMN // Habr. – 2022. – URL: https://habr.com/ru/articles/666112/ (дата обращения: 23.10.2025).
65. Как описать бизнес-процесс в BPMN, EPC и UML: примеры диаграмм // Babok School. – URL: https://babok.ru/metody-opisaniya-biznes-processov/ (дата обращения: 23.10.2025).
66. Нотация BPMN 2.0: ключевые элементы и описание // Блог Comindware. – URL: https://www.comindware.com/blog/bpmn-2-0-elements/ (дата обращения: 23.10.2025).
67. Как начать моделировать бизнес-процессы в BPMN // Школа системного анализа. – URL: https://system-education.ru/business-analyst/modeling-bpmn/ (дата обращения: 23.10.2025).
68. Нефункциональные требования к программному обеспечению. Часть 1 // Habr. – 2014. – URL: https://habr.com/ru/articles/230107/ (дата обращения: 23.10.2025).
69. Сбор и анализ требований // Бизнес-Анализ в России. – URL: https://www.b-analyst.ru/stat/analiz/sbor-i-analiz-trebovanij/ (дата обращения: 23.10.2025).
70. Функциональные и нефункциональные требования // Skypro. – URL: https://sky.pro/media/funkcionalnye-i-nefunkcionalnye-trebovaniya/ (дата обращения: 23.10.2025).
71. Описание и анализ бизнес-процессов // web-automation.ru. – URL: https://www.web-automation.ru/library/articles/description-and-analysis-of-business-processes (дата обращения: 23.10.2025).
72. Функциональные и нефункциональные требования // testengineer.ru. – URL: https://testengineer.ru/functional-vs-non-functional-requirements/ (дата обращения: 23.10.2025).
73. Метрики и KPI для IT проектов // iFellow. – URL: https://ifellow.ru/blog/metriki-i-kpi-dlya-it-proektov/ (дата обращения: 23.10.2025).
74. 10 KPI в IT, которые важно отслеживать // FSM-системы HubEx. – URL: https://hubex.ru/blog/10-kpi-v-it-kotorye-vazhno-otslezhivat/ (дата обращения: 23.10.2025).
75. Как оценить эффективность ИТ? // GlobalCIO|DigitalExperts. – URL: https://globalcio.ru/materials/14545/ (дата обращения: 23.10.2025).
76. Оценка ИТ проектов // HelpIT.me. – URL: https://helpit.me/ocenka-it-proektov/ (дата обращения: 23.10.2025).
77. Методы определения экономического эффекта от ИТ-проекта // iTeam. – URL: https://www.iteam.ru/articles/it/section_51/detail_385002 (дата обращения: 23.10.2025).
78. Как выбрать правильные KPI для оценки IT-инициатив // it-aurora.ru. – URL: https://it-aurora.ru/blog/kak-vybrat-pravilnye-kpi-dlya-ocenki-it-initsiativ/ (дата обращения: 23.10.2025).
79. Методический подход оценки экономической эффективности ИТ-проектов // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/metodicheskiy-podhod-otsenki-ekonomicheskoy-effektivnosti-it-proektov (дата обращения: 23.10.2025).
80. Считаем эффективность ИТ-проектов // БИТ. Бизнес & Информационные технологии. – URL: https://www.bit.ru/news/kak-schitat-effektivnost-it-proektov/ (дата обращения: 23.10.2025).
81. KPI по качеству управления ИТ-проектами для руководителя и команды // Habr. – 2024. – URL: https://habr.com/ru/articles/799432/ (дата обращения: 23.10.2025).
82. Показатели эффективности // inf.e-course.com.ua. – URL: https://inf.e-course.com.ua/glava_14_effektivnost_informacionnoj_sistemy/c142_pokazateli_effektivnosti.html (дата обращения: 23.10.2025).
83. 23 KPI для ИТ Сбалансированной системы показателей // BSC Designer. – URL: https://bsc-designer.com/ru/kpi-dlya-it-sbalansirovannoy-sistemy-pokazateley.html (дата обращения: 23.10.2025).
84. Методы оценки эффективности ИС предприятия // Научный аспект. – 2017. – № 2. – URL: https://na-journal.ru/2-2017-ekonomicheskie-nauki/300-metody-ocenki-effektivnosti-is-predpriyatiya (дата обращения: 23.10.2025).
85. TCO и ROI для CIO // Компьютерное Обозрение. – URL: https://ko.com.ua/tco_i_roi_dlya_cio (дата обращения: 23.10.2025).
86. Что такое кейс-стади (метод case study) // Генеральный Директор. – URL: https://www.gd.ru/articles/10904-keys-stadi (дата обращения: 23.10.2025).
87. Система сбалансированных показателей: определение, этапы внедрения и инструменты управления // InSales. – URL: https://www.insales.ru/blog/sistema-sbalansirovannyh-pokazatelej (дата обращения: 23.10.2025).
88. Система сбалансированных показателей, Balanced Scorecard, ССП-BSC // Uplab. – URL: https://www.uplab.ru/blog/balanced-scorecard/ (дата обращения: 23.10.2025).
89. Система сбалансированных показателей: что это такое и зачем нужен BSС // Клеверенс. – URL: https://cleverence.ru/blog/sistema-sbalansirovannykh-pokazateley-chto-eto-takoe-i-zachem-nuzhen-bsc/ (дата обращения: 23.10.2025).
90. Сбалансированная система показателей (ССП, Balanced Scorecard) // up-pro.ru. – URL: https://www.up-pro.ru/library/strategy/balanced-scorecard/ (дата обращения: 23.10.2025).
91. BSC (Сбалансированная система показателей) и Business Studio // Business Studio. – URL: https://www.businessstudio.ru/articles/repin/articles/bsc_and_business_studio/ (дата обращения: 23.10.2025).
92. Как управлять рисками в IT-проектах: советы от профессионалов // it-aurora.ru. – URL: https://it-aurora.ru/blog/kak-upravlyat-riskami-v-it-proektah/ (дата обращения: 23.10.2025).
93. Управление рисками в IT проектах // iFellow. – URL: https://ifellow.ru/blog/upravlenie-riskami-v-it-proektah/ (дата обращения: 23.10.2025).
94. Управление рисками проектов при внедрении IT-систем // Bpium. – URL: https://bpium.ru/blog/upravlenie-riskami-proektov-pri-vnedrenii-it-sistem/ (дата обращения: 23.10.2025).
95. УПРАВЛЕНИЕ ИНФОРМАЦИОННЫМИ РИСКАМИ ПРИ ВНЕДРЕНИИ ИНФОРМАЦИОННЫХ СИСТЕМ // Международный студенческий научный вестник. – 2017. – № 6. – URL: https://eduherald.ru/ru/article/view?id=12984 (дата обращения: 23.10.2025).
96. Как управлять рисками ИТ-проекта // Бизнес-секреты. – URL: https://www.tinkoff.ru/business/articles/upravlenie-riskami/ (дата обращения: 23.10.2025).
97. Как управлять рисками в IT проектах // Первый Бит. – URL: https://1cbit.ru/blog/kak-upravlyat-riskami-v-it-proektakh/ (дата обращения: 23.10.2025).
98. Как управлять рисками IT-проекта // Медиа Нетологии. – URL: https://netology.ru/blog/risk-management-it (дата обращения: 23.10.2025).
99. 5 проверенных стратегий снижения рисков // Acronis. – URL: https://acronis.com/ru-ru/blog/articles/risk-reduction-strategies/ (дата обращения: 23.10.2025).
100. УПРАВЛЕНИЕ РИСКАМИ ПРИ ВНЕДРЕНИИ ИНФОРМАЦИОННЫХ СИСТЕМ ПРЕДПРИЯТИЯ // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/upravlenie-riskami-pri-vnedrenii-informatsionnyh-sistem-predpriyatiya (дата обращения: 23.10.2025).
101. Как снизить риски при разработке ИТ-проекта // Umbrella IT. – URL: https://www.umbr.it/blog/kak-snizit-riski-pri-razrabotke-it-proekta/ (дата обращения: 23.10.2025).
102. Управление рисками проекта // Habr. – 2022. – URL: https://habr.com/ru/articles/646279/ (дата обращения: 23.10.2025).
103. Что такое управление ИТ-рисками? Полное руководство // ИН-КОМ. – URL: https://in-com.ru/chto-takoe-upravlenie-it-riskami/ (дата обращения: 23.10.2025).
104. МЕТОДИКА ОЦЕНКИ РИСКОВ ИТ-ПРОЕКТОВ // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/metodika-otsenki-riskov-it-proektov (дата обращения: 23.10.2025).
105. Почему проваливаются проекты внедрения? Топ-5 причин и возможные решения // up-pro.ru. – URL: https://www.up-pro.ru/library/information-technology/automation/pochemu-provalivayutsya-proekty-vnedreniya.html (дата обращения: 23.10.2025).
106. Управление рисками информационных технологий // ProКачество. – URL: https://prokachestvo.ru/articles/upravlenie-riskami-informatsionnykh-tekhnologiy/ (дата обращения: 23.10.2025).
107. Как провести анализ рисков бизнеса, методы и оценки // ПланФакт. – URL: https://planfact.io/blog/analiz-riskov-biznesa-metody-i-ocenki/ (дата обращения: 23.10.2025).
108. Риски в проекте: управление, поиск, оценка и стратегии решения // DIS Group. – URL: https://disgroup.ru/blog/riski-v-proekte-upravlenie-poisk-ocenka-i-strategii-resheniya/ (дата обращения: 23.10.2025).
109. Управление рисками в эпоху цифровизации: как минимизировать угрозы // it-aurora.ru. – URL: https://it-aurora.ru/blog/upravlenie-riskami-v-epohu-tsifrovizatsii/ (дата обращения: 23.10.2025).
110. 10 главных причин провала проектов // ADVANTA. – URL: https://www.advanta-group.ru/blog/10-glavnykh-prichin-provala-proektov/ (дата обращения: 23.10.2025).
111. Какие риски могут появиться у компаний при внедрении нового ПО? // ВДГБ. – URL: https://vdgb.ru/company/news/kakie-riski-mogut-poyavitsya-u-kompaniy-pri-vnedrenii-novogo-po/ (дата обращения: 23.10.2025).
112. Что такое анализ рисков? (Обзор) // Visure Solutions. – URL: https://visuresolutions.com/ru/blog/risk-analysis/ (дата обращения: 23.10.2025).
113. План управления рисками автоматизации компании // КиберЛенинка. – URL: https://cyberleninka.ru/article/n/plan-upravleniya-riskami-avtomatizatsii-kompanii (дата обращения: 23.10.2025).
114. Семь самых распространённых проектных рисков и способы их предотвращения // Asana. – URL: https://asana.com/ru/resources/project-risks (дата обращения: 23.10.2025).
115. Стратегии спасения проектов: Почему 37% проектов проваливаются? // Пмсофт. – URL: https://pmsoft.ru/blog/project-management/pochemu-provalivayutsya-proekty/ (дата обращения: 23.10.2025).
116. Глава 8. Риски проекта и управление ими // 1С:ИТС. – URL: https://its.1c.ru/db/projman/content/2275/hdoc (дата обращения: 23.10.2025).
117. 10 причин провала внедрения ERP // Блог ERP Band. – URL: https://erp-band.ru/blog/10-prichin-provala-vnedreniya-erp/ (дата обращения: 23.10.2025).
118. 10 распространённых рисков проекта и шаги по их устранению // Habr. – 2023. – URL: https://habr.com/ru/articles/723432/ (дата обращения: 23.10.2025).
119. 6 рисков при разработке программного обеспечения, которые всегда актуальны // it-aurora.ru. – URL: https://it-aurora.ru/blog/6-riskov-pri-razrabotke-programmnogo-obespecheniya/ (дата обращения: 23.10.2025).
120. Топ-8 причин провала IT-проектов (и как этого избежать) // ADPASS. – URL: https://adpass.ru/top-8-prichin-provala-it-proektov-i-kak-etogo-izbezhat/ (дата обращения: 23.10.2025).