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

Размещено на http://www.allbest.ru/

4

Размещено на http://www.allbest.ru/

Оглавление

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Приложения



Введение

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· введение;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 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 мультипликаторов. Такая модель позволяет учитывать предыдущий опыт реализации аналогичных проектов, что в действительности является чрезвычайно сложной и вместе с тем важной задачей.

2. В 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 для калибровки модели к определенной конкретной среде. Описываемая константа вычисляется с учетом двух аспектов технологии производства: технический и аспект, относящийся ко внешней среде объекта.

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

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

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

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

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

(5)

где

dy/dt - оценка трудоемкости приведенная к единице времени.

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

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

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

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

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

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

Группа	Фактор	SLIM	SEER	COCOMO II	COCOMO
Атрибуты размера	Функциональные точки	Да	Да	Да	Да
	Объектно-ориентированные метрики	Да	Да	Да	Нет
Атрибуты системы	Тип системы	Да	Да	Нет	Нет
	Сложность	Да	Да	Да	Да
	Требуемая надежность	Нет	Нет	Да	Нет
Атрибуты персонала	Возможности персонала	Да	Да	Да	Да
	Занятость персонала	Нет	Нет	Да	Нет
	Компетенции персонала	Да	Да	Да	Да
Атрибуты проекта	Инструменты и техники	Да	Да	Да	Да
	Уязвимости/риски	Да	Да	Да	Нет
	Производственная программа	Да	Да	Да	Да
	Информационная безопасность	Нет	Нет	Да	Нет
Активность	Подготовка	Да	Да	Да	Да
	Разработка	Да	Да	Да	Да
	Завершение	Да	Да	Да	Да
	Переход на техническое обслуживание	Да	Да	Да	Да

1.4 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(6)

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

(7)

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

(8)

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

(9)

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

(10)

где

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

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

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

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

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

(11)

где

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

I - уровень инфляции.

r - премия за риск.

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

(12)

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

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

(13)

где

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

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

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

V - сумма стоимости займов и собственного капитала.

Rd - ставка доходности заемного капитала.

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

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

(14)

где

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

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

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

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

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

(15)

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

(16)



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· о внесении изменений и дополнений в Закон от 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,2 M], добавлен 17.01.2011
  

• Основные стадии создания автоматической системы управления

  Описание предпроектной (разработка технико-экономического обоснования) и проектной (создание технического и рабочего проекта) стадий разработки автоматической системы управления, ввод ее в эксплуатацию путем проведения монтажных и пусконаладочных работ.
  
  реферат [28,0 K], добавлен 25.10.2010
  

• Обоснование разработки справочно-информационной системы ИТ службы предприятия

  Номенклатура и объем производства продукции предприятия, эффективность использования трудовых ресурсов. Функциональная блок-схема бизнес-процесса сопровождения. Технико-экономическое обоснование разработки справочно-информационной системы "Транс-Альфа".
  
  курсовая работа [451,4 K], добавлен 06.08.2013
  

• Создание информационной системы предприятия в среде Adobe Dreamweaver

  Характеристика существующих технологий для разработки информационной системы. Проектирование реляционной базы данных информационной системы учета научных публикаций в среде Adobe Dreamweaver. Оценка функциональных возможностей системы учета публикаций.
  
  дипломная работа [2,0 M], добавлен 12.08.2015
  

• Разработка корпоративной информационной системы на примере ООО "Сибирский центр программного обеспечения"

  Анализ и разработка информационной системы, структура сети предприятия. Описание процесса разработки конфигураций и выявление потребностей в автоматизации функций. Средства разработки проектирования и архитектура базы данных. Разработка модели угроз.
  
  дипломная работа [1,4 M], добавлен 13.07.2011
  

• Автоматизированная информационная система художественной школы

  Задачи и стадии разработки автоматизированной информационной системы художественной школы. Описание предметной области с помощью бизнес-моделирования, использование диаграмм потоков данных DFD. Спецификация системы, логическая структура базы данных.
  
  курсовая работа [281,9 K], добавлен 12.07.2011
  

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

  Методологии разработки информационных систем в отечественной и зарубежной литературе. Государственные и международные стандарты в области разработки программного обеспечения. Разработка фрагмента информационной системы "Учебно-методический ресурс".
  
  курсовая работа [364,6 K], добавлен 28.05.2009
  

• Средства разработки информационных систем

  Понятие CASE-средств как программных средств, которые поддерживают процессы создания и сопровождения информационных систем (ИС). Особенности IDEF-технологии разработки ИС. Описание нотации IDEF0. Разработка функциональных моделей бизнес-процесса.
  
  презентация [399,8 K], добавлен 07.04.2013
  

• Функциональное моделирование SADT

  История возникновения стандарта IDEF0. Особенности процесса и концепции методологии функционального моделирования SADT, ее структура и применение. Пример практической разработки модели информационной системы "Управления федерального казначейства".
  
  курсовая работа [731,5 K], добавлен 09.10.2012
  

• Бизнес-проект разработки и внедрения автоматизированной информационной системы для музея

  Проблемы внедрения информационной системы. Процесс разработки и внедрения автоматизированной информационной системы на примере музея "Галерея изящных искусств". Рекомендации по устранению основных рисков или снижению степени их влияния на проект.
  
  курсовая работа [3,0 M], добавлен 07.05.2015
  

Другие документы, подобные "Автоматизированная система управления городскими финансами"

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