Современные корпоративные информационные системы играют ключевую роль в управлении бизнес-процессами, обеспечивая эффективное взаимодействие между различными подразделениями компании и автоматизируя рутинные операции. Одним из важных аспектов функционирования таких систем является работа с финансовыми документами, которые служат основой для принятия управленческих решений, анализа финансового состояния компании и выполнения обязательств перед контрагентами. При работе с документами в корпоративных ИС возникают различные проблемы, которые способны привести к ошибкам, задержкам, потерям и даже юридическим рискам [1]. Основными сложностями обработки данных служат некорректный ввод информации пользователями, некачественная интеграция между модулями, неструктурированная организация хранения данных и др.
В связи с этим механизмы обработки документов являются частым объектом доработки в ИТ-системах, так как от удобства, интуитивности и представительности этих средств напрямую зависит эффективность работы пользователей и как следствие всей организации [2]. Актуальность тематики данной статьи обусловлена растущими требованиями к скорости обработки финансовых данных, необходимостью минимизации ошибок при вводе и анализе информации, а также повышением требований к удобству программных интерфейсов. Современные подходы к проектированию приложений должны учитывать не только технические аспекты, но и интересы пользователей, что делает эту задачу многогранной и сложной.
1. Цель и задачи
Цель данной работы состоит в разработке программного средства, обеспечивающего массовый ввод финансовых данных в корпоративную систему SAP ERP. Реализация заявленной цели потребует решения следующих задач:
- анализ и выбор оптимальных методов и подходов для реализации КИС;
- сбор бизнес и пользовательских требований к реализуемому программному продукту;
- проектирование ИТ-архитектуры будущего решения в разрезе процессов, данных и приложений;
- реализация программного решения с использованием языков программирования VBA и ABAP;
- функциональное тестирование разработанного продукта.
2. Подходы к реализации КИС
Решение любой задачи требует анализа доступных способов ее реализации. Применительно к области информационных систем и технологий доступно несколько научных работ, способных описать ключевые вопросы к проработке: своды знаний по корпоративной архитектуре EABoK [3] и управлению проектами PMBoK [4], а также теория корпоративных информационных систем [5]. Согласно EABoK/TOGAF построение ИТ-архитектуры требует комплексной работы над:
- бизнес-процессами;
- данными;
- приложениями;
- техникой,
которые дополняются двумя поддерживающими активностями PMBoK:
- управление проектом;
- управление изменениями,
и обогащаются релевантными методами и подходами теории КИС. Тогда для реализации программного средства массового ввода финансовых данных необходимо выбрать:
- модель внедрения ПО;
- способ выявления требований к продукту;
- графические нотациями проектирования процессов;
- стратегию моделирования таблиц баз данных;
- подход к формированию структуры будущего приложения;
- вид тестирования разработанного решения,
что будет задавать стратегию доставки софтверного продукта.
2.1. Обзор моделей, методов и способов
2.1.1. Модели внедрения
Выделают три классические модели разработки программных продуктов и внедрения платформенных софтверных решений (рис. 1), в то время как общеизвестные методологии, например, ASAP, Agile Scrum и 1С: ТКВ, наследуют их принципы работы, максимально детализируя выполняемые задачи [6].
Каскадная модель – это классический линейный подход к разработке ПО, при котором процесс делится на строго последовательные этапы. Каждый этап должен быть полностью завершён до перехода к следующему. К типовым этапам относят:
- сбор и анализ требований, где определяются все функциональные и нефункциональные требования к продукту, фиксирующиеся в техническом задании;
- проектирования, здесь создаются ИТ-архитектура системы, структуры баз данных и интерфейсов, а также готовятся технические спецификации;
- реализации, подразумевающий написание кода в соответствии с проектной документацией;
- тестирования для проверки ПО на соответствие требованиям и отладки программных ошибок;
- перехода, включающий развертывание ИТ-системы и обучение пользователей;
- гиперподдержки, где исправляются продуктивные ошибки, возникающие на момент запуска.
Преимуществом модели являются четкая структура и понятный порядок действий для достижения результата, однако предварительные требования должны быть обязательно зафиксированы до старта работ. К недостаткам можно отнести сложности внесения изменения в ПО после старта работ над ним, позднее тестирование продукта и обнаружение ошибок, кроме того, существует риск устаревания требований во время реализации проекта, что может обесценить программный продукт.
Итерационная модель предполагает разбиение проекта на небольшие итерации, каждая из которых представляет собой мини-проект с собственным набором функций к реализации. После каждой итерации заказчик получает определенную версию продукта и может просить ее корректировку. К этапам работ можно отнести следующее:
- определение требований для всех итераций;
- планирование итерации (выбор требований к реализации);
- разработка;
- тестирование;
- демонстрация заказчику;
- сбор обратной связи;
- корректировка требований для всех итераций;
- планирование следующей итерации.
Плюсами данной модели служат ее гибкость (можно обновлять требования по ходу итерации), раннее тестирование и получение регулярной обратной связи от пользователей. Минусам является сложность оценки итоговых сроков, бюджета и трудозатрат, вероятен риск постоянных доработок при отсутствии четких критериев остановки.
Спиральная модель сочетает в себе каскадный и итерационный подходы, делая акцент на обработку рисков и обоснование решения о необходимости продолжения разработок. Здесь ведутся такие активности, как:
- определение требований для всех витков;
- планирование работ на текущем витке;
- разработка и тестирование;
- реагирование на возникающие риски;
- оценка результатов витка;
- принятие решения о переходе на следующий виток.
Помимо плюсов и минусов унаследованных моделей, преимуществом спиралевидной схемы является минимизация неожиданных проблем за счет своевременной обработки рисков, к недостаткам же относят высокие трудозатраты для проведения их анализа.
2.1.2. Методы сбора требований
Сбор требований – начальный и определяющий шаг работы над программным обеспечением, именно он задает границы проекта, ограничивая объем выполняемых задач. Ниже даны основные методы выявления требований [7]:
- интервью – прямое общение с заинтересованными сторонами: заказчиками, пользователями и экспертами. Интервью бывают: структурированные по заранее подготовленным вопросам и неструктурированные, например, свободная беседа. Интервью дает возможность адаптации вопросов по ходу беседы, однако требует время на подготовку и допускает риск искажения информации участниками;
- анкетирование – сбор данных через опросники. Плюсами анкетирования являются: охват широкой аудитории, возможность получения анонимных и честных ответов, экономия времени на проведение мероприятия, а минусами служат ограниченность ответов перечнем заданных вопросов и отсутствие возможности их уточнить;
- наблюдение – анализ деятельности пользователей в их рабочей среде. Преимущества метода заключаются в получении реальных данных и выявлении неочевидных проблем, к недостаткам можно отнести высокие временные затраты для контроля хода работы;
- рабочие сессии – совместные встречи с ключевыми сторонами для генерации идей. Идет коллективное обсуждение и быстрое выявление требований участниками, однако может наблюдаться доминирование одних сотрудников над другими;
- прототипирование – создание упрощённой версии программного продукта для демонстрации и сбора обратной связи от пользователей. Прототип обладает наглядностью, что удобно, когда требования к ПО размыты, однако необходимы серьезные трудозатраты на его подготовку.
2.1.3. Способы моделирования бизнес-процессов
Свод знаний по управлению бизнес-процессами BPM CBoK [8] задает графические нотации, позволяющие моделировать операции для состояний AS-IS и TO-BE. Переход из AS-IS в TO-BE осуществляется за счет выявления «узких мест» текущего процесса и их устранения в целевом состоянии.
Литературный источник, полная версия статьи
Кирюшин Д.С. Разработка механизма массовой загрузки финансовых документов в SAP ERP (часть 1) // Корпоративные информационные системы. – 2025. – №3 (31) – c. 19-30. – URL: https://corpinfosys.ru/archive/2025/issue-31/307-2025-31-massuploadinginsaperp.
