ПИВ АСУ ГФ — вход в личный кабинет, официальный сайт

Оглавление

Введение

Глава 1. Существующие методические
основы описания бизнес-архитектуры

.1 Описание и анализ подходов к
описанию бизнес-архитектуры

.2 Описание и анализ стандартов
составления технико-экономического обоснования

.3 Описание и анализ моделей оценки
стоимости разработки информационной системы

.4 Описание системы показателей
оценки эффективности разработки информационной системы

Глава 2.Описание бизнес-архитектуры

.1 Краткое описание объекта
автоматизации

.2 Основание для разработки
информационной системы

.3 Назначение и цели разработки
информационной системы

.3.1 Назначение информационной
системы

.3.2 Цели и задачи разработки
информационной системы

.4 Описание функциональных
возможностей

.5 Технологический план

.6 Организационный план

.7 Производственный план

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

.9 Расчет оценки стоимости
разработки информационной системы

.10 Расчет экономических показателей

.10.1 Расчет ставки дисконтирования

.10.2 Расчет экономических
показателей эффективности

Заключение

Библиографический список

Приложения

Введение

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

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

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

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

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

1. Проанализировать подходы к описанию
бизнес-архитектуры.

2.      Сравнить стандарты разработки
технико-экономических обоснований.

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

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

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

Глава 1.    Существующие
методические основы описания бизнес-архитектуры

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

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

1.1    Описание и анализ подходов к
описанию бизнес-архитектуры

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

Термин «архитектура» используется в сфере ИТ
достаточно часто. В большинстве случаев, его применяют к описанию предприятия,
информационной системы или автоматизируемым бизнес-процессам. Впервые данное
понятие было введено Дж. Захманом в 1987 г. в статье «Структура архитектуры
информационных систем» [1]. Опубликованная Дж. Захманом работа касалась
непосредственно архитектуры информационной системы в целом, однако именно она
легла в основу дальнейших разработок в части бизнес-архитектуры.

На данный момент, под термином
«бизнес-архитектура» подразумевают организационную структуру и бизнес-модель
автоматизируемого предприятия, документы, используемые в процессе разработки и
реализации программных продуктов. В действительности, в соответствии со
стандартом ANSI/IEEE 1471-2000 под архитектурой предприятия следует понимать
«фундаментальную организацию системы, реализованную в ее компонентах, связях
этих компонентов друг с другом и внешней средой и принципах, определяющих
структуру и развитие системы».

В соответствии с методологией The
Open Group
Architecture
Framework,
бизнес-архитектура предусматривает формализацию архитектуры деятельности
объекта автоматизации в соответствии с ранее утвержденным видением.

Опираясь на статью М. Платта [2],
бизнес-архитектура описывает принципы работы бизнеса: бизнес-стратегии и планы
по переходу организации из текущего состояния в будущее. Она состоит из
следующих компонентов: высокоуровневые цели и задачи автоматизируемого объекта,
бизнес-процессы, выполняемые бизнес-функции, основные организационные структуры
и связи между всеми описанными элементами.

В работе Е. Всяких, Е.
Сидоренко,
А. Зуевой, Б. Носкова, А. Киселёва «Практика и проблематика моделирования
бизнес-процессов» авторы рассмотрели следующие подходы к описанию
бизнес-архитектуры: «сверху вниз», «снизу вверх» и гибридный, который частично
включает в себя предыдущие два [3].

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

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

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

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

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

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

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

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

1.2    Описание и анализ стандартов
составления технико-экономического обоснования

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

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

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

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

.   Технико-экономическое обоснование разработки
АСУ (далее ТЭО АСУ) предназначено для обоснования необходимости и
технико-экономической целесообразности создания или развития новой
информационной системы.

2.      ТЭО АСУ создается как независимый
документ, составляемый при создании АСУ на действующих или реконструируемых
(реорганизуемых) объектах автоматизации или как раздел в сопутствующих
разработке документах.

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

.        Для вновь проектируемых объектов
управления, исходные данные, необходимые для написания разделов и подразделов
документа ТЭО АСУ, определяют на основе анализа аналогов.

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

В соответствии со стандартом, обязательными для
включения в документ, являются следующие разделы:

·  введение;

·        характеристика объекта и
существующей системы управления;

·        цели, критерии и ограничения
создания;

·        функции и задачи создаваемой
системы;

·        ожидаемые технико-экономические
результаты создания;

·        выводы и предложения.

Второй стандарт был разработан c
помощью United Nations Industrial
Development Organization (далее
UNIDO). Предложенный
UNIDO подход к
подготовке ТЭО, подразумевает под собой тот факт, что целью составления
документа является необходимость в принятии решений об инвестировании и
способах финансирования создания новых продуктов/услуг.

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

Предполагается, что в соответствии со
стандартом, разработанным UNIDO, ТЭО должно отражать описание следующих
положений:

.   Условия реализации проекта (описание
автоматизируемых в плановом периоде бизнес-процессов AS-IS),
уже проведенные ранее исследования в экономической и технической сферах
разработки.

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

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

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

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

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

Основным преимуществом описанного стандарта
является тот факт, что в результате проведенного анализа складывается
полноценное представление о специфике и особенностях осуществляемого проекта.
Однако, несмотря на это, стандарт не учитывает характер конкретно заданной
предметной области. В связи с этим, можно сделать вывод о том, что наиболее
подходящим стандартом, который следует использовать в процессе составления ТЭО
для автоматизированной системы управления городскими финансами, является – ГОСТ
24.202-80.

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

1.3     Описание и анализ моделей
оценки стоимости разработки информационной системы

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

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

.   COCOMO 81 (Constructive Cost Model) – это
эмпирическая модель оценки стоимости разработки, предложенная в 1981 году.
COCOMO 81 была создана с опорой на исследование 63 программных проектов
размерностью от 2 000 до 100 000 строк кода и написанных на языках
программирования, начиная с ассемблера [4].

Данные по описанным проектам были исследованы
для того чтобы обнаружить множество закономерностей и формул наиболее
подходящих для проведения наблюдений с использованием модели. Таким образом, в
рамках COCOMO 81, трудоемкость разработки системы – основа оценки ее стоимости,
которая выражается в человеко-месяцах – PM
(Person Months), напрямую зависит от ее размера, а также условий реализации
соответствующего проекта – EM
(Effort Multipliers) и рассчитывается следующим путем:

 (1)

где

“a”
и “b” – константы,
соответствующие определенным значениям в рамках модели.

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

.   В 1997 году создана усовершенствованная
модель оценки стоимости разработки информационной системы – COCOMO II.
Согласно обновленной модели, расчет ведется по формуле:

 (2)

Где 

 (3)

где

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

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

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

3. SEER (System Evaluation and
Estimation of Resources) – запатентованная
модель,
которая
принадлежит
корпорации
“Galorath Associates”. Принципы расчётов SEER
основаны на ранних исследовательских работах доктора наук Рэнделла Йенсена.
Основное уравнение, используемое в концепции модели:

 (4)

где

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

Ct –
константа, используемая для оценки технологии применяемой разработчиком.

– время, отведенное
на разработку информационной системы в годах.

K – общая стоимость
обеспечения жизненного цикла информационной системы в человеко-лет.

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

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

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

.   Модель оценки стоимости разработки SLIM
(Software
Life-Cycle
Model). Применяется в
основном для крупных проектов, где информационные системы по размерности
составляют 70 000 строк кода. Основана на распределении Рэлея – это
распределение вероятностей случайной величины “x” с плотностью [5].модель
использует два уравнения: уравнение измерения трудоемкости разработки
информационной системы и уравнение вычисления уровня производительности
информационной системы. Распределение Рэлея применяется в рамках модели с целью
оценки точности составления производственного графика разработки и учета
вероятности наступления тех или иных рисков. Таким образом, два ключевых
атрибута, предлагаемых к использованию в модели SLIM
– коэффициент производительности (PI)
и индекс трудоемкости (MBI).

Основная формула, применяемая при расчётах согласно
модели SLIM (включает
два вышеописанных уравнения):

 (5)

где

dy/dt
– оценка трудоемкости приведенная к единице времени.- общая стоимость
обеспечения жизненного цикла системы.

a – параметр
масштаба информационной системы.

t – прошедшее с
момента начала разработки время.

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

Как показал сравнительный анализ,
самым лучшим вариантом для оценки стоимости разработки информационной системы
«Автоматизированная система управления городскими финансами» является модель –
COCOMO II. Это связано с тем, что аналогичные модели в меньшем объеме учитывают
основные факторы, участвующие в оценке стоимости. В данном случае достоверность
оценки прямо пропорциональна количеству факторов, которые учитываются в
концепции модели.

Таблица 1. Сравнение моделей оценки
стоимости разработки информационных систем

1.4   

1.4 Описание системы показателей
оценки эффективности разработки информационной системы

Экономическая эффективность в самом общем смысле
есть сравнение результатов хозяйственной деятельности с затраченными на эту
деятельность ресурсами: трудовыми, материальными, природными [6].

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

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

1.   Показатели прибыльности

Ключевыми показателями прибыли являются:

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

·        себестоимость – прямые затраты,
связанные непосредственно с разработкой информационной системы;

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

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

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

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

2.   Показатели рентабельности

Обычно к ключевым показателям рентабельности
относят:

·    маржу – долю валовой прибыли в выручке (процент
стоимости, который нужно добавить, чтобы получить цену);

·        наценку – долю валовой прибыли в
себестоимости;

·        рентабельность продаж – долю чистой
прибыли в выручке;

·        рентабельность активов – долю чистой
прибыли в активах;

·        рентабельность собственного капитала
– долю чистой прибыли в собственном капитале.

Кроме разделения на показатели прибыльности и
показатели рентабельности показатели эффективности еще принято делить на:

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

2.      Абсолютные – отражают уровень развития
предприятия, достигнутый за определенный промежуток времени.

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

1)   валовая прибыль – разница между валовым
доходом и издержками, связанными с получением дохода;

 (6)

2)   операционная прибыль (прибыль до уплаты
процентов за кредит и налога на прибыль) – вычисляется как разница валовой
прибыли и амортизации;

 (7)

3)   чистый операционный доход (чистая прибыль)
– разница между операционной прибылью, налогами и процентами по кредитам;

 (8)

4)   чистый операционный денежный поток (в
основном используется как база для расчета других показателей) – вычисляется
как сумма чистой прибыли и амортизации;

 (9)

5)   чистая приведенная стоимость – разница
между суммой дисконтированных денежных потоков и первоначальными инвестициями.

 (10)

где

I0 – начальные
инвестиции, i – месячная ставка
дисконтирования [7].

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

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

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

I.       Кумулятивныйметод ставки дисконтирования представляет собой расчет по следующей
формуле:

 (11)

гдеmin
– минимальная реальная ставка дисконтирования (как правило, за минимальную
реальную ставку дисконтирования принимают 30-летние государственные облигации
США).- уровень инфляции.- премия за риск.

Премия за риск также является вычисляемым
показателем, и представляет собой следующую сумму:

 (12)

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

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

 (13)

где

Re – ставка
доходности собственного капитала.

E – рыночная
стоимость собственного капитала.

D – рыночная
стоимость заемного капитала.

V – сумма стоимости
займов и собственного капитала.d
– ставка доходности заемного капитала.

t – ставка налога на
прибыль.

Ставка доходности собственного капитала (Re)
вычисляется по формуле:

 (14)

где

Rf –
безрисковая ставка дохода.

β – коэффициент,
определяющий изменение цены на акции компании по сравнению с изменением цен на
акции по всем компаниям данного сегмента рынка.

Rm –
среднерыночная ставка доходности на фондовом рынке (Rm
– Rf – премия за
рыночный риск).

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

)        реальная годовая ставка дисконтирования:

  (15)

2)      реальная месячная ставка
дисконтирования:

 (16)

Глава 2.    Описание
бизнес-архитектуры

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

2.1     Краткое описание объекта
автоматизации

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

Свою деятельность в рамках реализации бюджетного
процесса Департамент финансов осуществляет в соответствии с постановлением от
22 февраля 2021 г. № 43-ПП «Об утверждении Положения о Департаменте финансов».

Порядок организационного, документационного,
информационного обеспечения деятельности Департамента финансов определяет
«Регламент Департамента финансов» (Приложение к Приказу Департамента финансов
от 23 апреля 2009 г. № 58, в редакции приказов Департамента финансов от 28
сентября 2009 г. № 108 и от 13 июля 2021 г. № 133).

Распределение ответственности между структурными
подразделениями Департамента Финансов за предоставление показателей по разделам
и подразделам классификации расходов бюджета, по главным распорядителям
бюджетных средств, по государственным программам, по источникам финансирования
дефицита бюджета определяет Приказ Департамента финансов № 36 «Об утверждении
перечней ответственных структурных подразделений Департамента финансов».

Этапы составления бюджета регламентированы
постановлением от 14 февраля 2021 г. № 42-ПП «Об утверждении Положения о
составлении проектов бюджета города и бюджета городского фонда обязательного
медицинского страхования на очередной финансовый год и плановый период».

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

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

1.   Приказ Министерства финансов Российской
Федерации от 08 июня 2021 г. № 90н «О внесении изменений в Указания о порядке
применения бюджетной классификации Российской Федерации, утвержденные приказом
Министерства финансов Российской Федерации от 1 июля 2021 г. № 65н».

2.      Приказ Министерства финансов Российской
Федерации от 22 сентября 2021 г. № 145н «Об утверждении Методических
рекомендаций по представлению бюджетов субъектов Российской Федерации и местных
бюджетов и отчетов об их исполнении в доступной для граждан форме».

.        Распоряжение Правительства Российской
Федерации от 30 декабря 2021 г. № 2593-р «Об утверждении Программы повышения
эффективности управления общественными (государственными и муниципальными)
финансами на период до 2021 года» о разработке информационных подсистем
управления государственными и муниципальными финансами публично-правовых
образований и организаций сектора государственного управления.

.        Постановление Правительства от 9
августа 2021 г. № 349-ПП «Об утверждении государственной программы
«Информационный город» на 2021-2021 годы» (в ред. Постановления Правительства
от 01.12.2021 №814-ПП).

4.1.   Подпрограмма 12.02.000.000.00. Повышение
эффективности реализации функций органами исполнительной власти за счет
внедрения информационно-коммуникационных технологий.

.1.1.  Мероприятие 12.02.002.000.00. Повышение
эффективности системы управления финансовой и экономической деятельностью за
счет внедрения информационно-коммуникационных технологий.

2.3 Назначение и цели разработки
информационной системы

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

2.3.1 Назначение информационной
системы

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

.   информационно-аналитической поддержке
процесса формирования доходной и расходной части бюджета;

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

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

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

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

Пользователями системы в плановом периоде
являются органы исполнительной власти, в т.ч.:

.   финансовый орган – Департамент финансов;

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

.        главные распорядители бюджетных средств
(далее ГРБС), распорядители бюджетных средств, главные администраторы доходов
бюджета.

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

2.3.2 Цели и задачи разработки
информационной системы

Основными целями разработки системы являются:

·  повышение эффективности процесса подготовки
расходной и доходной части проекта бюджета;

·        повышение открытости и прозрачности
бюджета;

·        повышение качества контроля
бюджетного процесса;

·        повышение эффективности формирования
и контроля исполнения планов финансово-хозяйственной деятельности учреждений;

Основными индикаторами достижения поставленных
целей являются:

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

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

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

Основными решаемыми задачами в процессе
разработки системы являются:

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

·        создание подсистем информационной
системы «Автоматизированная система управления городскими финансами»;

·        обеспечение возможности применения
кодов бюджетной классификации в соответствии с принципами, установленными
Федеральным законом от 22.10.2021 № 311-ФЗ.

2.4    Описание функциональных
возможностей

Функциональные возможности, требуемые к реализации
со стороны Исполнителя по разработке подсистемы «Планирование расходной части
бюджета»:

•  формирование бюджетных ограничений;

•        вариантное планирование расходной части
бюджета;

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

1. Модуль формирования бюджетных
ограничений.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       определение бюджетных ограничений
для проекта бюджета;

–       определение бюджетных ограничений в
автоматизированном режиме:

·        ведение дополнительных
классификаторов. (Исполнитель должен обеспечить первоначальное наполнение
дополнительных классификаторов на основании информации, предоставленной
Заказчиком);

·        определение расчетных показателей
бюджета (бюджетных ограничений) – инструментарий системы должен обеспечить
следующие возможности:

ü    индексация расходов в соответствии с
настроенными правилами, ведение и учет исключений из правил индексирования;

ü  ввод корректировочных поправок –
ввод экспертных корректировок для увеличения / сокращения объемов бюджетных
ассигнований;

–       ручной ввод бюджетных ограничений;

–       подготовка отчетности и
аналитических материалов на основании информации модуля.

2. Модуль вариантного планирования
расходной части бюджета.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       подготовка неограниченного числа
версий проекта бюджета – при этом новая версия проекта бюджета должна
создаваться только после утверждения предыдущей (последовательно);

–       ввод данных по проекту бюджета с
учетом бюджетных ограничений;

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

–       отправка ГРБС данных по проекту
бюджета, изменениям в проект бюджета на согласование в адрес Департамента
финансов;

–       согласование либо возврат на
доработку сотрудником Департамента финансов данных по проекту бюджета,
изменениям в проект бюджета в адрес ГРБС;

–       утверждение версии проекта бюджета;

–       подготовка приложений к закону о
бюджете по расходам.

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

Функциональная возможность должна обеспечивать
реализацию:

–       Методического обеспечения в части
планирования межбюджетных трансфертов;

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

Функциональным назначением модуля должно
являться обеспечение следующих возможностей:

–       обследование правового регулирования
и практики предоставления межбюджетных трансфертов за 2021-2021 годы, выявить
сильные и слабые стороны организации предоставления межбюджетных трансфертов;

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

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

·        распределения дотаций на
выравнивание бюджетной обеспеченности муниципальных образований;

·        правового регулирования
предоставления субвенций для осуществления переданных органам местного
самоуправления отдельных государственных полномочий;

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

–       разработка проектов нормативных
правовых актов, необходимых для реализации подготовленных предложений по
совершенствованию межбюджетных отношений, в том числе:

·        о внесении изменений и дополнений в
Закон от 10.09.2008 № 39 «О бюджетном устройстве и бюджетном процессе»;

·        об утверждении методик распределения
и предоставления межбюджетных трансфертов, разработка которых отнесена к
компетенции заказчика;

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

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

–       отображение перечня межбюджетных
трансфертов;

–       формирование расчета межбюджетных
трансфертов, в т.ч.:

·        ручной ввод исходных данных (данные,
используемые для расчетов) в разрезе муниципальных образований;

·        автоматический расчет суммы
межбюджетных трансфертов на основе алгоритмов расчета, заложенных в систему в
соответствии с разработанными проектами методик планирования объемов финансирования
межбюджетных трансфертов;

–       формирование приложений к закону о
бюджете в части межбюджетных трансфертов в формате Excel.

Внедрение программного принципа на
местном уровне.

Назначением модуля должно являться обеспечение
следующих возможностей:

–       методическое обеспечение в части
внедрения программного принципа на местном уровне;

–       прототип программного обеспечения по
представлению местных бюджетов в программном виде.

Методическое обеспечения в части внедрения
программного принципа на местном уровне должно обеспечивать:

–       разработку подходов к организации
комплексного внедрения программного принципа на местном уровне;

–       разработку нормативных-правовых и
методических документов, необходимых для внедрения программного принципа на
муниципальном уровне, в том числе:

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

·        типовые муниципальные правовые акты,
необходимые для перехода на программные принципы на муниципальном уровне;

·        типовые муниципальные программы для
одного пилотного муниципального образования в пилотных сферах;

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

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

–       формирование программ органа
местного самоуправления (далее – ОМСУ), в т.ч.:

·        определение состава программ
(добавление, удаление программы из перечня);

·        определение структуры программы;

·        ввод информации по разделам
программы (паспорт, показатели, финансирование и др.);

–       ввод сведений о реализации программ
ОМСУ (показатели, финансирование);

–       формирование отчетности в формате
Excel:

·        регламентного отчета по программе;

·        сводного отчета по всем программам
ОМСУ;

·        отчета об исполнении программы.

Мониторинг исполнения местных
бюджетов и оценка качества финансового менеджмента:

Назначением модуля должно являться обеспечение
следующих возможностей:

–       Разработка методического обеспечения
в части внедрения на муниципальном уровне оценки качества финансового менеджмента
на муниципальном уровне;

–       Прототип программного обеспечения по
проведению оценки качества финансового менеджмента на муниципальном уровне;

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

Методическое обеспечения в части внедрения на
муниципальном уровне оценки качества финансового менеджмента должно
обеспечивать:

–       разработку подходов к внедрению на
муниципальном уровне оценки качества финансового менеджмента;

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

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

Функциональные возможности, требуемые к
реализации со стороны Исполнителя по разработке подсистемы «Планирование и
анализ доходной части бюджета»:

•  вариантное планирование расходной доходной
бюджета.

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

Подсистема «Автоматизированное рабочее место
руководителя Департамента финансов» предназначена для визуализации информации о
бюджете, а также предоставления руководителю Департамента финансов функций
мобильного офиса.

В рамках выполнения работ по разработке
веб-приложения должны быть разработаны механизмы:

–    формирования и вывода на печать графика
мероприятий;

–       выгрузки экранных форм в файлы
форматов Adobe PDF и MS
Excel;

–       разграничения прав пользователей,
позволяющие выдавать разрешения на редактирование определённых разделов;

–       журналирования действий
пользователей.

Исполнителем также должны быть разработаны
инструменты:

–    согласования пакетов документов на внесение
изменений в сводную бюджетную роспись с использованием электронной подписи;

–       ввода и отображения еженедельной
отчетной информации по государственному долгу;

–       ввода и отображения информации по
исполнению доходной части бюджета;

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

–       предоставления функций мобильного
офиса заместителям руководителя Департамента финансов.

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

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

·        реализация механизма проверки
открытой части ключа электронной подписи (далее ЭП);

·        реализация механизма проверки
электронной подписи;

·        реализация механизма включения
штампа времени в ЭП;

Подсистема «Аналитической обработки данных»
должна быть предназначена для консолидации информации о бюджетном процессе и
социально-экономическом развитии.

В рамках выполнения работ по развитию подсистемы
должны быть разработаны:

·  механизмы ведения реестра открытых данных
Департамента финансов и передача их на «Портал открытых данных Правительства»;

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

2.5    Технологический план

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

Характеристики окружающей среды в местах
установки технических средств должны соответствовать требованиям следующих
документов:

·  ГОСТ Р ИСО 14001-98. Системы управления
окружающей средой. Требования и руководство по применению.

·        СанПиН 2.2.24.548-96. Физические
факторы производственной среды. Гигиенические требования к микроклимату
производственных помещений.

·        СанПиН 2.2.2/2.4.1340-03.
Гигиенические требования к персональным электронно-вычислительным машинам и
организации работы.

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

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

Рабочие места пользователей должны
функционировать под управлением операционных систем MS Windows 2000/XP/Vista/7.
На рабочих местах пользователей должно быть установлено следующее программное
обеспечение:

·  браузер Mozilla
Firefox 18.0, Google Chrome 24.0 (и
выше),
Internet Explorer 9 (и выше);

·        Microsoft Office 2007 (и выше).

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

·  операционная система Microsoft Windows Server
2008 R2;

·        СУБД
Microsoft SQL Server 2008 R2 или
Oracle 11gR2.

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

·  операционная система
Microsoft Windows Server 2008 R2;

·        Microsoft Internet
Information Server 7.0 (и выше)
или
Apache Tomcat 7;

·        Microsoft .Net Framework 4.0.

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

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

Амортизационные группы определены по
государственному классификатору.

2.6 Организационный план

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

Существует шесть основных типов организационных
структур:

1. линейная;

2.      функциональная;

.        линейно-функциональная;

.        матричная;

.        дивизиональная;

.        множественная.

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

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

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

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

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

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

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

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

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

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

Согласно техническому заданию,
опубликованному среди прочих документов на web-странице
конкурса (сайт государственных закупок), состав задействованных в разработке
системы сотрудников должен соответствовать перечню, представленному в Таблице 3.

Таблица 3. Квалификационный состав
проектной команды

2.7   Производственный план

Сокращенный вариант
производственного плана реализации разработки и развития информационной системы
«Автоматизированная система управления городскими финансами» может быть
представлена в виде Таблицы 4. Полная версия производственного плана содержится
в Приложении B.

Таблица 4. Первый уровень
декомпозиции производственного плана

Первый этап «Обследование объекта автоматизации
и уточнение требований к системе» содержит подзадачи:

.       Обследование и уточнение требований:

.1.    Уточнение основных требований к
подсистеме «Планирование и анализ доходной части бюджета».

1.2.   Уточнение основных требование к
подсистеме «Планирование расходной части бюджета».

.3.     Уточнение основных требований к
подсистеме «Автоматизированное рабочее место руководителя Департамента
финансов».

.4.     Уточнение основных требований к
подсистеме аналитической обработки данных.

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

2.   Обеспечение информационной безопасности
(далее ИБ):

2.1.  Анализ обрабатываемых документов и
классификация.

2.2.   Анализ угроз и описание потенциальных
угроз и действий нарушителя ИБ.

.3.     Анализ и формирование требований по
обеспечению ИБ.

3.   Документирование:

3.1.  Оформление и согласование отчета об
обследовании.

3.2.   Описание бизнес-сценариев
автоматизируемых процессов.

.3.     Оформление и согласование частного
технического задания.

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

Второй этап «Техно-рабочий проект системы в
рамках реализации функций первой части» более объемный и содержит подзадачи:

1. Системное проектирование.

2.      Внедрение юридически значимого
электронного документооборота:

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

.        Разработка подсистемы «Планирование и
анализ доходной части бюджета».

.        Разработка подсистемы «Планирование
расходной части бюджета».

.        Разработка подсистемы
«Автоматизированное рабочее место руководителя Департамента финансов».

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

8. Создание модуля формирования предложений по
распределению предельных объемов бюджетных ассигнований.

9.      Создание модуля обеспечения
информационного взаимодействия с Фондом капитального ремонта.

.        Создание подсистемы «Обеспечения
юридической значимости».

.        Интеграционное тестирование и отладка.

.        Документирование:

12.1.     Технический проект:

12.1.1.  Пояснительная записка к техническому
проекту системы.

12.1.2.        Описание архитектуры системы.

12.2.     Рабочая документация:

12.2.1.  Общее описание системы.

12.2.2.        Руководство пользователя системы.

.2.3.  Руководство администратора системы.

.2.4.  Программа и методика предварительных испытаний.

.2.5.  Программа опытной эксплуатации системы.

.2.6.  Акт ввода системы в опытную эксплуатацию
(проект).

12.3.     Ведомость машинных носителей
информации.

13. Пуско-наладочные работы.

14.    Предварительные испытания.

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

Третий этап «Техно-рабочий проект системы в рамках
реализации функций второй части» по объему работ близок похож на второй и
содержит подзадачи:

1.   Системное проектирование

2.      Развитие подсистемы «Планирование
расходной части бюджета».

.        Развитие подсистемы «Планирование и
анализ доходной части бюджета».

.        Развитие подсистемы «Автоматизированное
рабочее место руководителя Департамента финансов».

.        Реализация информационного
взаимодействия с информационной системой «Электронный бюджет».

.        Создание подсистемы аналитической
обработки данных.

.        Развитие подсистемы «Обеспечения
юридической значимости».

.        Разработка подсистемы «Сводная
бюджетная роспись».

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

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

.        Интеграционное тестирование и отладка.

.        Документирование:

12.1.     Технический проект:

.1.1.      Пояснительная записка к техническому
проекту системы.

12.1.2.        Описание архитектуры системы.

12.2.     Рабочая документация:

.2.1.      Общее описание системы.

12.2.2.        Руководство пользователя системы.

.2.3.  Руководство администратора системы.

.2.4.  Программа и методика предварительных
испытаний системы.

.2.5.  Программа опытной эксплуатации системы.

.2.6.  Акт ввода системы в опытную эксплуатацию
(проект).

.2.7.  Ведомость машинных носителей информации.

13. Пуско-наладочные работы.

14.    Предварительные испытания.

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

Четвертый этап «Опытная эксплуатация и приемка
системы» является завершающим и содержит подзадачи:

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

.1.  Техническое и сервисное сопровождение новых
компонент системы.

1.2.   Проведение оптимизации подсистем.

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

2.   Документирование:

.1.  План-программа подготовки персонала.

2.2.   Отчет о подготовке персонала.

.3.     Акт о проведении подготовки персонала.

.4.     Журнал проведения опытной эксплуатации.

.5.     Акт о завершении опытной эксплуатации.

.6.     Программа и методика комплексных приемочных
испытаний.

.7.     Акт о готовности системы к промышленной
эксплуатации.

3.   Комплексные приемочные испытания.

4.      Проектный офис:

4.1.       Общее управление проектом.

4.2.   Координация проектной команды.

.3.     Администрирование проекта.

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

Общие затраты на реализацию разработки системы
составляют 148 рабочих дней.

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

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

Таблица 5. Перечень диаграмм,
описывающих процесс разработки

2.9 Расчет оценки стоимости
разработки информационной системы

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

 (17)

где

а – комплексный коэффициент, полученный путем
обработки информации по большому количеству проектов разработки программного
обеспечения за длительный промежуток времени (в рамках исследования коэффициент
а = 2,94).

Size – сумма
строк кода, представленная в тыс. строк (KSLOC).- множители трудоемкости
разработки.

  (18)

где

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

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

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

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

·  количество строк кода, подсчитанное исходя из
оценки User Function Types (логических групп данных, которые используются и
поддерживаются системой, и функциональности совершаемых транзакций);

·        интегральная оценка масштабируемости
проекта;

·        интегральные множители трудоемкости.

Вычисление Size(количество
строк кода, выраженное в тысячах строк):

Для вычисления количество строк кода по модели
COCOMO-II необходимо произвести оценку User
Function
Types (логических групп
данных и функциональности совершаемых транзакций в системе), после чего,
согласно таблице весов (Model
Definition
Manual), определить
ненормированное количество функциональных точек (Unadjusted
Function
Point, UFP). Далее для
предполагаемого языка программирования следует определить коэффициент отношения
строчек кода к UFP (Model
Definition
Manual) и на основании
данного коэффициента и числа UFP подсчитать Size.

Общая функциональность определяется путем:

1.   Анализа логических групп данных, которые
используются и поддерживаются системой (точки типа ILF и EIF):

·        ILF
– Internal
Logical File
– внутренний логический файл (логически связанная группа данных, определяемая
пользователем и находящаяся внутри границ проекта).

·        EIF
– External
Interface
Files – внешний
интерфейсный файл (логически связанная группа данных, обеспечивающая
программное обеспечение информацией, но лежащая за его пределами и
поддерживаемая другим программным обеспечением).

2.   Анализа функциональности совершаемых
транзакций (точки типа EInp, EO и EInq):

·        EInp
– External
Input – внешний вход
(процесс ввода данных и управляющей информации).

·        EO – External Output – внешний выход
(процесс, генерирующий данные или управляющую информацию, которые поступают на
выход ПО. Обычно процесс вида EO представляет собой формирование различных
экранов, отчетов, сообщений);

·        EInq – External Inquiry – внешний
запрос (диалоговый ввод, который приводит к немедленному ответу ПС в форме
диалогового вывода).

Итоговое количество функциональных
точек в системе представлено в Таблица6. Оно составляет 4 027,5 ед.

Таблица 6. Количество User Function
Types в системе

На основе данных, полученных из инструкции Model
Definition Manual к модели COCOMO-II, коэффициент UFP для языка Java (Eclipse),
на котором в плановом периоде будет реализована большая часть подсистем
составляет 53.

Таким образом, число строк кода составляет 4
027,5 x 53 = 213 457,5, а переменная Size,
(количество строк кода, выраженная в тысячах строк) – 213, 46.

Вычисление Е – интегральной оценки
масштабируемости проекта:

Методика COCOMO II позволяет оценить влияние
масштабов проекта на эффективность процесса разработки программного продукта.
Данная зависимость в формуле расчета трудоемкости оценивается коэффициентом
масштаба E.

Е – интегральная оценка масштабируемости проекта
рассчитывается на основании оценки факторов масштаба и имеет вид:

  (19)

где

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

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

В Таблица 7 представлена оценка
состояния масштабирующих факторов, проведенная на основе значений, полученных с
помощью использования инструкции Model Definition Manual созданной специально
для COCOMO-II.

Таблица 7. Перечень параметров
масштабируемости системы

В итоге значение показателя масштабируемости
составляет:

,91 0,01 x
(1,24 3,04 4,24 3,29 3,12) = 1,059 ед.

Вычисление EMi – множителей
трудоемкости:

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

В Таблице 8 приведена оценка
состояния множителей трудоемкости, значений EMi, полученных на основе данных
технического задания и инструкции Model Definition Manual к модели COCOMO-II.

Таблица 8. Оценка множителей
трудоемкости

Итого  1,518 ед.

Итоговый расчет трудоемкости
разработки системы:

Трудоемкость проекта в человеко-месяцах в
соответствии с моделью COCOMO II равна: PM = 2, 94 x 213,461,0593 x 1,518 = 1
309,03 ед.

Для определения стоимости разработки
системы требуется вычислить стоимость единицы трудоемкости (см. Таблица 9)

Таблица 9. Перечень расходов,
составляющих стоимость единицы трудоемкости

Стоимость 1 человеко-дня вычисляется как
стоимость 1 человеко-месяца умноженная на 12 (количество месяцев в году) и
деленная на 247 (количество рабочих дней в 2021 году).

Среднемесячная заработная плата работников за
январь-май 2021 года по полному кругу организаций, на основе данных Мосгорстата
по виду деятельности «Разработка программного обеспечения и консультирование в
этой области» составляет в среднем 58 052,90 руб.

Расчет суммарного размера тарифов
страховых взносов в 2021 году, представленный в табличном формате – Таблица 10.

Таблица 10. Страховые взносы в ПФ,
ФМС, ФСС

Расчет размера накладных расходов в
% от фонда оплаты труда, представленный в табличном формате – Таблица 11.

Таблица 11. Полный перечень
накладных расходов на реализацию проекта

Стоимость работ по разработке и вводу в
промышленную эксплуатацию системы определяется из стоимости 1 человеко-месяца,
умноженного на итоговую трудоемкость работ: 135 586,84 x
1 309,03 = 177 487 241,17 руб.

2.10  Расчет экономических
показателей

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

2.10.1         Расчет ставки
дисконтирования

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

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

i = ((1 0,08305) /
(1 0,0063)) – 1 = 0,07627

Переводим годовую реальную ставку
дисконтирования в месячную:

i= (((1 (0,07627 /
100)) ^ (1/12)-1) * 100) = 0,00635

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

2.10.2         Расчет экономических
показателей эффективности

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

·    Расчет срока окупаемости инвестиций
(Pay-Back Period):

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

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

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

·    Расчет прибыли до уплаты процентов и
налога (Operation Income):

В результате расчетов, получаем значение: Ol =
92 399,5 тыс. руб. за весь период реализации проект. Такая сумма не является
критичной, т.к. в рамках проекта нет установленного временного ограничения на
получение фиксированного минимума.

·    Расчет прибыли после уплаты налогов
и выплаты процентов по кредитам (Net Operation Income):

В результате расчетов, получаем значение: NOI=
60 185,9 тыс. руб. за весь период реализации проекта. Такое значение показателя
является удовлетворительным и соответствует положительной динамике поступления
доходов от реализации проекта.

Заключение

В данной работе приведено описание
бизнес-архитектуры, проведено анализ экономической и технической рациональности
реализации информационной системы «Автоматизированная система управления
городскими финансами», составлен специальный документ – технико-экономическое
обоснование (представлено в Приложении G).
Представлено максимально детальное описание планируемых к реализации
функциональных возможностей системы.

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

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

·  повышение эффективности деятельности органов
исполнительной власти и государственных учреждений;

·        обеспечение открытости и
прозрачности деятельности органов исполнительной власти и государственных
учреждений;

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

Библиографическийсписок

1.Zachman J. A Framework for
Information Systems Architecture // IBM Systems Journal. 1987. Vol 16, pp 276 –
292.

.Обзор архитектуры Microsoft //
Microsoft Developer Network [Электронный ресурс] [Режим доступа:
https://msdn.microsoft.com/ru-ru/library/ee872883.aspx] [Проверено:
27.04.2021].

3.Всяких Е., Сидоренко Е., Зуева А.,
Носков Б., Киселёв С. Практика и проблематика моделирования бизнес-процессов. М:
ДМК Пресс, 2008.

.Barry Boehm. Software
engineering economics. Englewood Cliffs, NJ:Prentice-Hall, 1981. ISBN
0-13-822122-7

.Jorgen M, Sjoberg D.I.K, “The
Impact of Customer Expectation on Software Development Effort Estimates” International
Journal of Project Management, Elsevier, pp 317-325, 2004

6.Щеренкова О. Оценка экономической
эффективности инвестиционных проектов // Финансовый менеджмент – 2005 – Вып.3.

.Дамодаран А. Инвестиционная оценка.
– 2-е изд. – М.: Альпина Бизнес Букс, 2004.

.Типовые организационные структуры
предприятий // Корпоративный менеджмент [Электронный ресурс] [Режим доступа: #”896537.files/image019.jpg”>

Рисунок 1. Матричная организационная
структура

Приложение B.
Производственный план проекта

Таблица 12. Производственный план
реализации разработки АСУГФ

Приложение C.
Модель, иллюстрирующая 1 уровень декомпозиции бизнес-процессов

Рисунок 2. Value Added Chain Diagram (1)

Приложение D.
Модель, иллюстрирующая 2 уровень декомпозиции бизнес-процессов

Рисунок 3.Value Added Chain Diagram (2)

Приложение E. Модель,
иллюстрирующая бизнес-процесс разработки системы

Рисунок 4. Extended Event driven Process Chain
Diagram (фрагмент
1)

Рисунок 5. Extended Event driven Process Chain
Diagram (фрагмент
2)

Приложение F.
Модель, иллюстрирующая окружение бизнес-процесса разработки системы

Рисунок 6. Function Allocation Diagram

Приложение G.Технико-экономическое обоснование

ДЕПАРТАМЕНТ ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ

ВЫПОЛНЕНИЕ
НАУЧНО-ИССЛЕДОВАТЕЛЬСКИХ И ОПЫТНО-КОНСТРУКТОРСКИХ РАБОТ

ПО СОЗДАНИЮ АВТОМАТИЗИРОВАННОЙ
СИСТЕМЫ УПРАВЛЕНИЯ ГОРОДСКИМИ ФИНАНСАМИ

АСУ ГФ

Технико-экономическое
обоснование

На 27
листах

2021
г

Оглавление

1. ВВЕДЕНИЕ

1.1
Основание для проведения работ

.2
Наименование организации-заказчика

.3
Наименование организаций – участников работ

.4
Сроки начала и окончания работ

.5
Источники, объемы, порядок финансирования работ

.
ХАРАКТЕРИСТИКА ОБЪЕКТА И СУЩЕСТВУЮЩЕЙ СИСТЕМЫ УПРАВЛЕНИЯ

.1 Общая
характеристика объекта

.2
Характеристика производственно-хозяйственной деятельности

.3
Перечень и характеристика недостатков

. ЦЕЛИ
СОЗДАНИЯ АСУ ГФ

.1
Назначение информационной системы

.2
Цели и задачи разработки информационной системы

.
ФУНКЦИИ СОЗДАВАЕМОЙ АСУ ГФ

.1
Перечень реализуемых функций

.3.
Требования к перспективам развития

5.
ОЖИДАЕМЫЕ ТЕХНИКО-ЭКОНОМИЧЕСКИЕ РЕЗУЛЬТАТЫ СОЗДАНИЯ

5.1
Расчет оценки стоимости разработки информационной системы

.1
Расчет экономических показателей

5.1.1
Расчет ставки дисконтирования

.1.2
Расчет экономических показателей эффективности

6. ВЫВОДЫ

1.      ВВЕДЕНИЕ

1.1    Основание для проведения работ

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

.Приказ Министерства финансов Российской
Федерации от 08 июня 2021 г. № 90н «О внесении изменений в Указания о порядке
применения бюджетной классификации Российской Федерации, утвержденные приказом
Министерства финансов Российской Федерации от 1 июля 2021 г. № 65н».

.Приказ Министерства финансов Российской
Федерации от 22 сентября 2021 г. № 145н «Об утверждении Методических
рекомендаций по представлению бюджетов субъектов Российской Федерации и местных
бюджетов и отчетов об их исполнении в доступной для граждан форме».

.Распоряжение Правительства Российской Федерации
от 30 декабря 2021 г. № 2593-р «Об утверждении Программы повышения
эффективности управления общественными (государственными и муниципальными)
финансами на период до 2021 года» о разработке информационных подсистем
управления государственными и муниципальными финансами публично-правовых
образований и организаций сектора государственного управления.

.Постановление Правительства от 9 августа 2021
г. № 349-ПП «Об утверждении государственной программы «Информационный город» на
2021-2021 годы» (в ред. Постановления Правительства от 01.12.2021 №814-ПП).

.1.Подпрограмма 12.02.000.000.00. Повышение
эффективности реализации функций органами исполнительной власти за счет
внедрения информационно-коммуникационных технологий.

.1.1.Мероприятие 12.02.002.000.00. Повышение
эффективности системы управления финансовой и экономической деятельностью за
счет внедрения информационно-коммуникационных технологий.

1.2 Наименование организации-заказчика

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

Функциональный заказчик работ: Департамент
финансов города Москвы.

1.3 Наименование
организаций – участников работ

Исполнитель работ определяется на конкурсной
основе в соответствии с действующим законодательством.

.4 Сроки начала и окончания работ

Начало окончание работ определяются в
соответствии с условиями конкурсной документации.

.5 Источники, объемы, порядок финансирования
работ

Источником финансирования работ является бюджет
города Москвы.

. ХАРАКТЕРИСТИКА ОБЪЕКТА И СУЩЕСТВУЮЩЕЙ СИСТЕМЫ
УПРАВЛЕНИЯ

.1 Общая характеристика объекта

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

Свою деятельность в рамках реализации бюджетного
процесса Департамент финансов осуществляет в соответствии с постановлением от
22 февраля 2021 г. № 43-ПП «Об утверждении Положения о Департаменте финансов».

Порядок организационного, документационного,
информационного обеспечения деятельности Департамента финансов определяет
«Регламент Департамента финансов» (Приложение к Приказу Департамента финансов
от 23 апреля 2009 г. № 58, в редакции приказов Департамента финансов от 28
сентября 2009 г. № 108 и от 13 июля 2021 г. № 133).

Распределение ответственности между структурными
подразделениями Департамента Финансов за предоставление показателей по разделам
и подразделам классификации расходов бюджета, по главным распорядителям бюджетных
средств, по государственным программам, по источникам финансирования дефицита
бюджета определяет Приказ Департамента финансов № 36 «Об утверждении перечней
ответственных структурных подразделений Департамента финансов».

Этапы составления бюджета регламентированы
постановлением от 14 февраля 2021 г. № 42-ПП «Об утверждении Положения о
составлении проектов бюджета города и бюджета городского фонда обязательного
медицинского страхования на очередной финансовый год и плановый период».

.2 Характеристика производственно-хозяйственной
деятельности

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

.3 Перечень и характеристика недостатков

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

Однако до настоящего времени:

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

•не осуществлена полная автоматизация с
последующей интеграцией всех процессов управления финансово-хозяйственной
деятельности организаций;

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

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

3. ЦЕЛИ СОЗДАНИЯ АСУ ГФ

3.1 Назначение информационной системы

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

.информационно-аналитической поддержке процесса
формирования доходной и расходной части бюджета;

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

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

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

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

Пользователями системы в плановом периоде
являются органы исполнительной власти, в т.ч.:

.финансовый орган – Департамент финансов;

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

.главные распорядители бюджетных средств (далее
ГРБС), распорядители бюджетных средств, главные администраторы доходов бюджета.

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

.2 Цели и задачи разработки информационной
системы

Основными целями разработки системы являются:

•повышение эффективности процесса подготовки
расходной и доходной части проекта бюджета;

•повышение открытости и прозрачности бюджета;

•повышение качества контроля бюджетного
процесса;

•повышение эффективности формирования и контроля
исполнения планов финансово-хозяйственной деятельности учреждений;

Основными индикаторами достижения поставленных
целей являются:

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

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

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

Основными решаемыми задачами в процессе
разработки системы являются:

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

•создание подсистем информационной системы
«Автоматизированная система управления городскими финансами»;

•обеспечение возможности применения кодов
бюджетной классификации в соответствии с принципами, установленными Федеральным
законом от 22.10.2021 № 311-ФЗ.

. ФУНКЦИИ СОЗДАВАЕМОЙ АСУ ГФ

4.1 Перечень реализуемых функций

Функциональные возможности, требуемые к
реализации со стороны Исполнителя по разработке подсистемы «Планирование
расходной части бюджета»:

•  формирование бюджетных ограничений;

•        вариантное планирование расходной части
бюджета;

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

1. Модуль формирования бюджетных
ограничений.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       определение бюджетных ограничений
для проекта бюджета;

–       определение бюджетных ограничений в
автоматизированном режиме:

ведение дополнительных классификаторов.
(Исполнитель должен обеспечить первоначальное наполнение дополнительных
классификаторов на основании информации, предоставленной Заказчиком);

определение расчетных показателей бюджета
(бюджетных ограничений) – инструментарий системы должен обеспечить следующие
возможности:

ü    индексация расходов в соответствии с
настроенными правилами, ведение и учет исключений из правил индексирования;

ü  ввод корректировочных поправок –
ввод экспертных корректировок для увеличения / сокращения объемов бюджетных
ассигнований;

–       ручной ввод бюджетных ограничений;

–       подготовка отчетности и
аналитических материалов на основании информации модуля.

2. Модуль вариантного планирования
расходной части бюджета.

Модуль должен обеспечивать реализацию следующих
возможностей:

–       подготовка неограниченного числа
версий проекта бюджета – при этом новая версия проекта бюджета должна
создаваться только после утверждения предыдущей (последовательно);

–       ввод данных по проекту бюджета с учетом
бюджетных ограничений;

–       отправка ГРБС данных по проекту
бюджета, изменениям в проект бюджета на согласование в адрес Департамента
финансов;

–       согласование либо возврат на доработку
сотрудником Департамента финансов данных по проекту бюджета, изменениям в
проект бюджета в адрес ГРБС;

–       утверждение версии проекта бюджета;

–       подготовка приложений к закону о
бюджете по расходам.

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

Функциональная возможность должна обеспечивать
реализацию:

–       Методического обеспечения в части
планирования межбюджетных трансфертов;

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

Функциональным назначением модуля должно
являться обеспечение следующих возможностей:

–       обследование правового регулирования
и практики предоставления межбюджетных трансфертов за 2021-2021 годы, выявить
сильные и слабые стороны организации предоставления межбюджетных трансфертов;

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

–       формирование предложений в части
расчета межбюджетных трансфертов, в т.ч. в части:

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

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

правового регулирования предоставления субвенций
для осуществления переданных органам местного самоуправления отдельных
государственных полномочий;

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

–       разработка проектов нормативных
правовых актов, необходимых для реализации подготовленных предложений по
совершенствованию межбюджетных отношений, в том числе:

о внесении изменений и дополнений в Закон от
10.09.2008 № 39 «О бюджетном устройстве и бюджетном процессе»;

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

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

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

–       отображение перечня межбюджетных
трансфертов;

–       формирование расчета межбюджетных
трансфертов, в т.ч.:

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

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

–       формирование приложений к закону о
бюджете в части межбюджетных трансфертов в формате Excel.

Внедрение программного принципа на
местном уровне.

Назначением модуля должно являться обеспечение
следующих возможностей:

–       методическое обеспечение в части
внедрения программного принципа на местном уровне;

–       прототип программного обеспечения по
представлению местных бюджетов в программном виде.

Методическое обеспечения в части внедрения
программного принципа на местном уровне должно обеспечивать:

–       разработку подходов к организации
комплексного внедрения программного принципа на местном уровне;

–       разработку нормативных-правовых и
методических документов, необходимых для внедрения программного принципа на
муниципальном уровне, в том числе:

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

типовые муниципальные правовые акты, необходимые
для перехода на программные принципы на муниципальном уровне;

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

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

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

–       формирование программ органа местного
самоуправления (далее – ОМСУ), в т.ч.:

определение состава программ (добавление,
удаление программы из перечня);

определение структуры программы;

ввод информации по разделам программы (паспорт,
показатели, финансирование и др.);

–       ввод сведений о реализации программ
ОМСУ (показатели, финансирование);

–       формирование отчетности в формате
Excel:

регламентного отчета по программе;

сводного отчета по всем программам ОМСУ;

отчета об исполнении программы.

Мониторинг исполнения местных
бюджетов и оценка качества финансового менеджмента:

Назначением модуля должно являться обеспечение
следующих возможностей:

–       Разработка методического обеспечения
в части внедрения на муниципальном уровне оценки качества финансового
менеджмента на муниципальном уровне;

–       Прототип программного обеспечения по
проведению оценки качества финансового менеджмента на муниципальном уровне;

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

Методическое обеспечения в части внедрения на
муниципальном уровне оценки качества финансового менеджмента должно
обеспечивать:

–       разработку подходов к внедрению на
муниципальном уровне оценки качества финансового менеджмента;

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

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

Функциональные возможности, требуемые к
реализации со стороны Исполнителя по разработке подсистемы «Планирование и
анализ доходной части бюджета»:

•  вариантное планирование расходной доходной
бюджета.

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

Подсистема «Автоматизированное рабочее место
руководителя Департамента финансов» предназначена для визуализации информации о
бюджете, а также предоставления руководителю Департамента финансов функций
мобильного офиса.

В рамках выполнения работ по разработке
веб-приложения должны быть разработаны механизмы:

–    формирования и вывода на печать графика
мероприятий;

–       выгрузки экранных форм в файлы
форматов Adobe
PDF и MS
Excel;

–       разграничения прав пользователей,
позволяющие выдавать разрешения на редактирование определённых разделов;

–       журналирования
действий пользователей.

Исполнителем также должны быть разработаны
инструменты:

–    согласования пакетов документов на внесение
изменений в сводную бюджетную роспись с использованием электронной подписи;

–       ввода и отображения еженедельной
отчетной информации по государственному долгу;

–       ввода и отображения информации по
исполнению доходной части бюджета;

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

–       предоставления функций мобильного офиса
заместителям руководителя Департамента финансов.

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

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

·        реализация механизма проверки
открытой части ключа электронной подписи (далее ЭП);

·        реализация механизма проверки
электронной подписи;

·        реализация механизма включения
штампа времени в ЭП;

Подсистема «Аналитической обработки данных»
должна быть предназначена для консолидации информации о бюджетном процессе и
социально-экономическом развитии.

В рамках выполнения работ по развитию подсистемы
должны быть разработаны:

·  механизмы ведения реестра открытых данных
Департамента финансов и передача их на «Портал открытых данных Правительства»;

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

.2 Требования к перспективам развития

Проектные решения, применяемые при разработке
первой очереди АСУ ГФ, должны обеспечивать возможность дальнейшего развития и
модернизации как программного обеспечения, так и комплекса технических средств.

При разработке должны быть предусмотрены:

•возможность увеличения производительности
системы путем её масштабирования;

•увеличение количества систем, участвующих в
информационном взаимодействии.

5.      ОЖИДАЕМЫЕ ТЕХНИКО-ЭКОНОМИЧЕСКИЕ
РЕЗУЛЬТАТЫ СОЗДАНИЯ

5.1.   Расчет оценки стоимости разработки
информационной системы

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

 (1)

где

а – комплексный коэффициент, полученный путем
обработки информации по большому количеству проектов разработки программного
обеспечения за длительный промежуток времени (в рамках исследования коэффициент
а = 2,94).

Size – сумма
строк кода, представленная в тыс. строк (KSLOC).

EMi – множители трудоемкости
разработки.

 (2)

где

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

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

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

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

·  количество строк кода, подсчитанное исходя из
оценки User Function Types (логических групп данных, которые используются и
поддерживаются системой, и функциональности совершаемых транзакций);

·        интегральная оценка масштабируемости
проекта;

·        интегральные множители трудоемкости.

Вычисление Size(количество
строк кода, выраженное в тысячахстрок):

Для вычисления количество строк кода по модели COCOMO-II
необходимо произвести оценку User
Function
Types (логических групп
данных и функциональности совершаемых транзакций в системе), после чего,
согласно таблице весов (Model
Definition
Manual), определить
ненормированное количество функциональных точек (Unadjusted
Function
Point, UFP).
Далее для предполагаемого языка программирования следует определить коэффициент
отношения строчек кода к UFP
(Model Definition
Manual) и на основании
данного коэффициента и числа UFP
подсчитать Size.

Общая функциональность определяется
путем:

3.   Анализа логических групп данных, которые
используются и поддерживаются системой (точки типа ILF
и EIF):

·        ILF
– Internal
Logical File
– внутренний логический файл (логически связанная группа данных, определяемая
пользователем и находящаяся внутри границ проекта).

·        EIF
– External
Interface
Files – внешний
интерфейсный файл (логически связанная группа данных, обеспечивающая
программное обеспечение информацией, но лежащая за его пределами и
поддерживаемая другим программным обеспечением).

4.   Анализа функциональности совершаемых
транзакций (точки типа EInp, EO и EInq):

·        EInp
– External
Input – внешний вход
(процесс ввода данных и управляющей информации).

·        EO
– External
Output – внешний выход
(процесс, генерирующий данные или управляющую информацию, которые поступают на
выход ПО. Обычно процесс вида EO
представляет собой формирование различных экранов, отчетов, сообщений);

·        EInq
– External
Inquiry – внешний запрос
(диалоговый ввод, который приводит к немедленному ответу ПС в форме диалогового
вывода).

Итоговое количество функциональных точек в
системе представлено в Таблица1. Оно
составляет 4 027,5 ед.

Таблица 1. Количество User Function Types в
системе

На основе данных, полученных из инструкции Model
Definition
Manual к модели COCOMO-II,
коэффициент UFP для языка Java
(Eclipse), на котором в
плановом периоде будет реализована большая часть подсистем составляет 53.

Таким образом, число строк кода составляет 4
027,5
x 53 = 213457,5,
а переменная Size,
(количество строк кода, выраженная в тысячах строк) – 213, 46.

Вычисление Е – интегральной оценки
масштабируемости проекта:

Методика COCOMO
II позволяет оценить
влияние масштабов проекта на эффективность процесса разработки программного
продукта. Данная зависимость в формуле расчета трудоемкости оценивается
коэффициентом масштаба E.

Е – интегральная оценка масштабируемости проекта
рассчитывается на основании оценки факторов масштаба и имеет вид:

 (3)

где

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

SF – факторы,
отражающих особенности проекта и коллектива разработчиков.

В Таблица 2 представлена оценка состояния
масштабирующих факторов, проведенная на основе значений, полученных с помощью
использования инструкции Model
Definition
Manual созданной специально
для COCOMO-II.

Таблица 2. Перечень параметров масштабируемости
системы

В итоге значение показателя масштабируемости
составляет:

,91 0,01 x
(1,24 3,04 4,24 3,29 3,12) = 1,059 ед.

Вычисление EMi
– множителей трудоемкости:

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

В Таблица 3 приведена оценка состояния
множителей трудоемкости, значений EMi,
полученных на основе данных технического задания и инструкции Model
Definition
Manual к модели COCOMO-II.

Таблица 3. Оценка множителей трудоемкости

Итого  1,518 ед.

Итоговый расчет трудоемкости
разработки системы:

Трудоемкость проекта в человеко-месяцах в
соответствии с моделью COCOMO
II равна: PM
= 2, 94 x 213,461,0593 x
1,518 = 1 309,03 ед.

Для определения стоимости разработки системы
требуется вычислить стоимость единицы трудоемкости (см. Таблица 4)

Таблица 4. Перечень расходов, составляющих
стоимость единицы трудоемкости

Стоимость 1 человеко-дня вычисляется как
стоимость 1 человеко-месяца умноженная на 12 (количество месяцев в году) и
деленная на 247 (количество рабочих дней в 2021 году).

Среднемесячная заработная плата работников за
январь-май 2021 года по полному кругу организаций, на основе данных Мосгорстата
по виду деятельности «Разработка программного обеспечения и консультирование в
этой области» составляет в среднем 58 052,90 руб.

Расчет суммарного размера тарифов страховых
взносов в 2021 году, представленный в табличном формате – Таблица 5.

Таблица 5. Страховые взносы в ПФ, ФМС, ФСС

Расчет размера накладных расходов в % от фонда
оплаты труда, представленный в табличном формате – Таблица 6.

Таблица 6. Полный перечень накладных расходов на
реализацию проекта

Стоимость работ по разработке и вводу в
промышленную эксплуатацию системы определяется из стоимости 1 человеко-месяца,
умноженного на итоговую трудоемкость работ: 135 586,84
x 1
309,03
= 177
487
241,17
руб.

5.1.   Расчет экономических показателей

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

.1.1   Расчет ставки дисконтирования

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

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

i = ((1 0,08305) /
(1 0,0063)) – 1 = 0,07627

Переводим годовую реальную ставку
дисконтирования в месячную:

i= (((1 (0,07627 /
100)) ^ (1/12)-1) * 100) = 0,00635

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

5.1.2 Расчет экономических показателей
эффективности

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

·    Расчет срока окупаемости инвестиций
(Pay-Back Period):

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

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

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

·    Расчет прибыли до уплаты процентов и
налога (Operation Income):

В результате расчетов, получаем значение: Ol =
92 399,5 тыс. руб. за весь период реализации проект. Такая сумма не является
критичной, т.к. в рамках проекта нет установленного временного ограничения на
получение фиксированного минимума.

·    Расчет прибыли после уплаты налогов
и выплаты процентов по кредитам (Net Operation Income):

В результате расчетов, получаем значение: NOI=
60 185,9 тыс. руб. за весь период реализации проекта. Такое значение показателя
является удовлетворительным и соответствует положительной динамике поступления
доходов от реализации проекта.

6. ВЫВОДЫ

Разработка и внедрение АСУ ГФ будет
способствовать созданию:

•инструментов повышения эффективности управления
деятельностью ОИВ, основанных на программно-целевом принципе организации их
деятельности

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

•единой методологии управления государственными
финансами г. Москвы

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

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

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

•повышение эффективности деятельности органов
исполнительной власти и государственных учреждений г. Москвы

•обеспечение открытости и прозрачности
деятельности органов исполнительной власти и государственных учреждений г.
Москвы

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

Аннотация

Выпускная квалификационная работа на тему
«Технико-экономическое обоснование разработки информационной системы «Автоматизированная
система управления городскими финансами» написана в соответствии с учебным
планом факультета «Бизнес-информатика» Пермского филиала федерального
государственного автономного образовательного учреждения высшего
профессионального образования «Национальный исследовательский университет
“Высшая школа экономики”, утвержденным в Государственном образовательном
стандарте высшего профессионального образования «Направление 080500.62.
Бизнес-информатика».

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

Автор: Базлова Мария Геннадьевна.

Факультет бизнес-информатики. 4 курс. 2021 г.

Объем работы: 87 стр.

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