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

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



Таблица 2.3 - Исходные данные для факторного анализа прибыли от реализации продукции

Показатели	План	План, пересчитаный на фактический объем реализации продукции	Факт
Выручка от реализации продукции (чистая), млн.руб.	627998	570502	826082
Полная себестоимость реализованной продукции, млн.руб.	514882	467742	713819
Прибыль от реализации продукции, млн.руб.	59602	54145	48750

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

Таблица 2.4 - Результаты факторного анализа балансовой прибыли

Факторы	Расчет влияния	Уровень показателя
1. Изменение объема реализованной продукции		10848
2. Изменение структуры реализованной продукции		-16305
3. Изменение себестоимости реализованной продукции		246077
4. Изменение среднего уровня цен		255580
Итого:		496200

Рентабельность - относительный показатель прибыли.

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

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

а) рентабельность производственной деятельности (окупаемости затрат продукции):

(2.1)

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

б) рентабельность продаж (оборота):

(2.2)

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

в) рентабельность капитала (доходность предприятия):

(2.3)

Расчеты показателей рентабельности по предприятию сведены в таблице 2.5.

Таблица 2.5 - Анализ показателей рентабельности

Показатели	Прошлый год	Отчетный год	Изменение, (+,-)
1. Выручка от реализации продукции, млн.руб.	627998	826082	198084
2. Полная себестоимость реализованной продукции, млн.руб.	514882	713819	198937
3. Прибыль, млн.руб.	59602	48750	-10852
4. Среднегодовая стоимость основных фондов и оборотных средств, млн.руб.	867735	1107133	239398
5. Рентабельность производственной деятельности (стр.3:стр.2*100%)	11,58	6,83	-4,75
6. Рентабельность продаж (стр.3:стр.1*100%)	9,49	5,90	-3,59
7. Рентабельность капитала (стр.3:стр.4*100%)	6,87	4,40	-2,47

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

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

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

- структуры реализованной продукции;

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

- среднего уровня цен реализации.

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

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

- увеличение объема реализации продукции;

- снижение ее себестоимости;

- повышение качества товарной продукции;

- реализация ее на более выгодных рынках сбыта и так далее.

Существенным резервом роста прибыли является улучшение качества товарной продукции[11].

2.7 Оценка финансового состояния предприятия РПДУП «Экспериментальный завод» РУП НПЦ НАН Беларуси

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

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

- коэффициент текущей ликвидности;

- коэффициент обеспеченности собственными оборотными средствами;

- коэффициент обеспеченности финансовых обязательств активами К3.

Динамика коэффициента текущей ликвидности (коэффициент покрытия долгов), характеризующего общую обеспеченность предприятия оборотными средствами для ведения хозяйственной деятельности и своевременного погашения срочных обязательств, показывает, что этот показатель вырос с 1,726 до 2,476, при норме не менее 1,5. Это говорит о том, что текущие активы покрывают текущие пассивы. Чем больше величина этого покрытия, тем больше уверенность кредиторов, что долги будут погашены. По заводу этот коэффициент составил на 1.01.2010 - 2,58 и на 1.01.2011 - 2,91.

Коэффициент быстрой или «критической» ликвидности - это отношение суммы денежных средств, краткосрочных финансовых вложений и дебиторской задолженности, платежи по которой ожидаются в течение 12 месяцев после отчетной даты, к сумме краткосрочных финансовых обязательств. По объединению на начало отчетного года составил 0,86, а на конец отчетного года - 1,10; по заводу и на начало года - 1,06 и на конец года - 1,38. Удовлетворительным является показатель от 0,7 до 1. При уровне 0,7-0,8 его величина считается достаточной.

Коэффициент абсолютной ликвидности (норма денежных резервов) дополняет предыдущие показатели. Чем выше его величина, тем больше гарантия погашения долгов. По объединению он составил на 1.01.2010 - 0,18, на 1.01.2011 - 0,69 и по заводу на начало года - 0,23 и на конец года - 0,89. Значение коэффициента признается достаточным, если он не превышает 0,20-0,25.

Рисунок 2.6 - Диаграмма динамики коэффициента текущей ликвидности

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

Рисунок 2.7 - Диаграмма динамики коэффициента обеспеченности собственными оборотными средствами

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

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

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

- коэффициент текущей ликвидности на конец отчетного периода в зависимости от отраслевой принадлежности организации имеет значение менее минимально допустимого значения(1,5);

- коэффициент обеспеченности собственными оборотными средствами на конец отчетного периода в зависимости от отраслевой принадлежности организации имеет значения менее минимально допустимого значения (0,2) [12].

Данные для анализа приведены в таблице 2.6.

Таблица 2.6 - Анализ показателей финансовой устойчивости предприятия

№	Наименование показателя	На начало года	На конец отчетного периода (момент установления неплатежеспособности)	Норматив коэффициента
1	Коэффициент текущей ликвидности K1	1,726	2,476	К1 >= 1,5
2	Коэффициент обеспеченности собственными оборотными средствами К2	0,421	0,596	К2 >= 0,2
3	Коэффициент обеспеченности финансовых обязательств активами К3	0,451	0,226	К3 <= 0,85

Общая сумма средств в абсолютном выражении увеличилась. Распределение средств между оборотным и внеоборотными активами составляет соответственно по объединению - 59,0% и 41,0%, по заводу - 54.4% и 45,6%. Необходимо отметить увеличение удельного веса оборотных активов. Более подробно структура актива рассматривается в приложении.

Приобретение имущества предприятия, производственная деятельность осуществляется за счет собственных и заемных средств, соотношение которых раскрывает сущность его финансового положения. Собственные средства на конец отчетного года составили по объединению 79,0%, по заводу 79,4%. Долгосрочные обязательства соответственно 3,5% и 4,2%. Краткосрочные заемные средства по объединению составили примерно 17%. Кредиторская задолженность 11,7%.

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

На 1.01.2011 года на расчетных счетах предприятий объединения имелись средства в сумме 974 млн. рублей, на валютных счетах - 27169 млн. рублей, прочие денежные средства- 3169 млн. рублей. Денежные средства в кассах составили 10 млн. рублей.

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

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

2.8 Анализ текущего уровня автоматизации работы планово-экономического отдела РПДУП «Экспериментальный завод» РУП НПЦ НАН Беларуси

На сегодняшний день сотрудники планово-экономического отдела РПДУП «Экспериментальный завод» используют в своей повседневной деятельности одну из самых распространенных программ для автоматизации бухгалтерского учета «1С: Бухгалтерия», а также возможности СУБД Excel.

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

Если оценивать «1С: Бухгалтерию» объективно, то ее нельзя назвать ни плохой, ни хорошей, поскольку неправильно давать оценочную характеристику данной программе без привязки к конкретному предприятию. Для некоторых организаций «1С: Бухгалтерия» является идеальным вариантом, полностью удовлетворяющим их требования. А для некоторых компаний данная программа не подходит, поскольку не способна в полной мере решить поставленные перед ней задачи. Рассмотрим основные недостатки «1С: Бухгалтерии»:

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

б) При переходе на «1С: Бухгалтерию» с другой бухгалтерской программы могут возникнуть серьезные затруднения при переносе информации из одной базы данных в другую (значительную часть информации нередко приходится переносить вручную).

в) Программа «1С: Бухгалтерия» достаточно сложна в освоении и требует специального обучения пользователей.

Использование СУБД Excel для автоматизации ведения отчетности сопряжено со следующими недостатками:

- низкая производительность при работе с большими объемами данных;

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

- нет многопользовательского доступа;

- большие трудности с консолидацией данных;

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

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

3. Разработка модуля автоматизация процессов ведения отчетности планово-экономического отдела

3.1 Определение требований к системе с точки зрения предметной области

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

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

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

MySQL версии 3.22 имеет предел по размеру таблиц 4 Гб. В MySQL версии 3.23, где используется новый тип таблиц, максимальный размер таблицы доведен до 8 миллионов терабайтов (2 ^ 63 bytes). Помимо этого в MySQL существует ряд способов, позволяющих увеличить производительность работы с таблицей и минимизировать требуемое пространство памяти.

в) Доступ к данным в СУБД должен осуществляться через драйвер, предоставляемый производителем СУБД.

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

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

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

3.2 Постановка задачи и обзор методов ее решения

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

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

- сбор и долгосрочное хранение информации, поступающей в виде отчетов;

- проверка корректности данных отчетов;

- оперативный выбор данных отчетности;

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

- получение входных данных и формирование выходных в виде таблиц Excel.

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

- интуитивный, легкий в освоении и не требующий долгого обучения интерфейс системы;

- организация удобного диалога ЭВМ и пользователя;

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

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

- интеграция с Excel.

Функциональная модель системы представлена в приложении А.

3.3 Спецификация системы

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

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

Рисунок 3.1 - Диаграмма вариантов использования системы

Таким образом система реализует три основных функциональности:

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

1) импортировать данные о потребностях в сырье и материалах в формате .xls;

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

3) автоматически создать отчет о калькулировании заказа;

4) экспортировать отчет о калькулировании заказа в формат .xls;

5) автоматически создать отчет о технологических расчетах;

6) экспортировать отчет о технологических расчетах в формат .xls

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

1) провести анализ финансового состояния предприятия;

2) провести анализ платежеспособности предприятия и оборачиваемости его ОС;

3) импортировать данные баланса предприятия из формата .xls;

4) получить результаты анализа в табличном и графическом виде;

5) просмотреть результаты предыдущих анализов;

6) получить справочную информацию.

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

1) Импортировать данные о доведенных показателях развития из формата .xls;

2) Импортировать отчеты о выполнении основных показателей развития из формата .xls;

3) Автоматически создать отчёт прогноза основных показателей развития на заданный период;

4) Экспортировать результаты планирования в формат .xls.

3.4 Информационная модель системы

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

Скрипт генерации базы данных представлен в приложении Г.

На физическом уровне информационная модель данного проекта показана на рисунке 3.2:

Рисунок 3.2 - Физический уровень информационной модели

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

Рисунок 3.3 - Логический уровень информационной модели

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

Ссылку на таблицу Order содержат таблицы:

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

б) CostCalculation - таблица с отчетом сметы по статьям калькуляции заказа. Содержит данные о наименовании статьи калькуляции и её стоимости.

Таблица Users хранит сведения о пользователе, его имени и должности.

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

а) Users, описана выше, также используется для персонализации данных;

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

Поле id таблицы Balance является внешним ключом для ряда таблиц, представляющих собой хранилища данных, импортируемых из пяти стандартных форм баланса предприятия: BookerBalanceF1 (форма 1 - бухгалтерский баланс), ProfitLossReportF2 (форма 2 - прибыль, убытки), ChangesInCapitalReportF3 (форма 3 - отчет об изменении капитала), CashFlowReportF4 (форма 4 - отчет о движении денежных средств), ApplicationToBalanceF5 (форма 5 - дополнение к бухгалтерскому балансу).

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

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

3.5 Модели представления системы

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

- диаграмма состояний (statechart);

- диаграмма взаимодействий (sequence);

- диаграмма классов (class);

- диаграмма компонентов (component);

- диаграмма развёртывания (deployment).

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

Рисунок 3.4 - Диаграмма состояний системы

Диаграмма взаимодействий. Для моделирования взаимодействия объектов в языке UML используются соответствующие диаграммы взаимодействия. Диаграмма взаимодействий отражает последовательность команд и вызовов методов для реализации основных функций бизнес-логики практически любого процесса [15]. С точки зрения концепции Model-View-Controller (MVC, «Модель-представление-контроллер») проиллюстрируем данное взаимодействие на рисунке 3.5:

Рисунок 3.5 - Диаграмма взаимодействий

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

Основные действия по отображению и обработке данных выполняются средствами фреймворка Symfony с использованием технологии AJAX.

При загрузке любой страницы формируется запрос (http Request) к соответствующему контроллеру. Контроллер обеспечивает связь между пользователем и системой: контролирует ввод данных пользователем и использует модель и представление для реализации необходимой реакции. Далее контроллер запрашивает данные (Data) у модели. Модель предоставляет знания: данные и методы работы с этими данными, реагирует на запросы, изменяя своё состояние. После этого контроллер обращается к представлению, комбинируя полученные данные от модели с шаблоном. В итоге контроллер возвращает на страницу сформированные HTML данные (http Response).

Диаграмма классов. Диаграммы классов (Class Diagram) при моделировании объектно-ориентированных систем встречаются чаще других. На таких диаграммах показывается множество классов, интерфейсов, коопераций и отношений между ними. Диаграммы классов используются для моделирования статического вида системы с точки зрения проектирования [15].

Архитектура данного приложения построена на основе паттерна проектирования Model-View-Controller, что и обуславливает структуру созданных классов.

Диаграмма классов разработанного модуля автоматизации процессов ведения отчетности планово-экономического отдела представлена в приложении В.

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

Основными компонентами разработанного программного кода являются классы, логически разделенные ввиду концепции MVC на 3 главных пакета: Models, Views, Controllers. Пакет Classes является инкапсулятором главных используемых классов. Диаграмма проиллюстрирована на рисунке 3.6.

Рисунок 3.6 - Диаграмма компонентов

3.5.5 Диаграмма развёртывания. Диаграмма развертывания предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime). При этом представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками. Диаграмма развертывания содержит графические изображения процессоров, устройств, процессов и связей между ними [15].



Рисунок 3.7 - Диаграмма развёртывания

На диаграмме, изображенной на рисунке 3.7, в роли клиента выступает браузер, установленный в ОС Windows 7.

Для функционирования серверной части, на сервере должен работать так называемый «движок» PHP, установленный в ОС Windows, а также Apache HTTP Server, для работы в сети Интернет. Для работы БД необходим установленный на сервере базы данных MySQL сервер.

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

3.7 Руководство пользователя по развертыванию системы

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

В локальном режиме на компьютере сотрудника планово-экономического отдела должен работать так называемый «движок» PHP, установленный в ОС Windows, а также Apache HTTP Server, для работы в сети Интернет. Для работы БД необходим установленный MySQL сервер. В представленном случае, данные компоненты являются достаточными.

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

а) Произвести регистрацию доменного имени.

Прежде чем зарегистрировать имя сайта, необходимо проверить: не занято ли оно. И это можно легко сделать при помощи многочисленных сервисов проверки свободных доменов (например, http://www.nic.ru/dns/).

Далее на данном сервисе можно осуществить быстрый подбор доменного имени в форме, расположенной ниже:

Рисунок 3.8 - Форма быстрого подбора доменного имени

Теперь можно приступать непосредственно к регистрации доменного имени. Воспользовавшись центром регистрации доменов RU center, перейти к регистрации, кликнув по ссылке «Для клиентов». Далее необходимо заполнить анкету (ссылка «заполнить анкету»). После того, как всё заполнено следует нажать «Отправить анкету» и получить письмо на e-mail с данными по активации аккаунта. Теперь можно войти в панель управления, указав номер договора и пароль в форме для входа.



Рисунок 3.9 - Доступ в панель управления

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

Рисунок 3.10 - Вид панели управления

б) Разместить сервис на хостинге.

1) При помощи фтп (ftp) браузера. Этот вариант считается самым небезопасным.

2) Через панель управления хостингом. Считается самым безопасным вариантом.

3) При помощи фтп (ftp) клиентов.

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



3.8 Результаты тестирования системы

Итак, у нас есть полностью функционирующий сервис, размещенный в сети Интернет. Как осуществить к нему доступ, подробно изложено в предыдущей главе. Теперь обратим внимание на знакомство с самим сервисом и его тестирование. Форма авторизации, рисунок 3.11:

Рисунок 3.11 - Стартовая страница авторизации

Здесь происходит поиск вводимых данных в базе, и если пользователь в ней не найден, то выдается ошибка авторизации (рис. 3.12):

Рисунок 3.12 - Ошибка авторизации

После авторизации загружается главная страница приложения, сверху страницы располагается удобное информационное сообщение, содержащее ФИО сотрудника (рис. 3.13):



Рисунок 3.13 - Стартовая страница приложения

Далее сотрудник может перейти в раздел калькуляции заказов. На рисунках 3.14 - 3.28 отображается процесс работы сотрудника с модулем калькуляции заказов.

Рисунок 3.14 - Просмотр списка заказов

Рисунок 3.15 - Результат удаления заказа

Рисунок 3.16 - Окно добавления нового заказа

Рисунок 3.17 - Форма загрузки файла технологического расчета

Рисунок 3.18 - Исходный файл технологического расчета

Рисунок 3.19 - Результаты загрузки файла технологического расчета

Рисунок 3.20 - Автоматическое заполнение столбца стоимости материалов

Рисунок 3.21 - Итог заполнения таблицы технологического расчета и вызов команды экспорта таблицы в Excel

Рисунок 3.22 - Результат работы команды экспорта таблицы в Excel



Рисунок 3.23 - Результат расчета сметы затрат на сырье и материалы

Рисунок 3.24 - Заполненная форма расчета стоимости (калькуляции) нового заказа

Рисунок 3.25 - Результат работы команды экспорта таблицы в Excel



Рисунок 3.26 - Результат калькуляции стоимости заказа

Рисунок 3.27 - Форма редактирования заказа

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

Рисунок 3.28 - Список последних созданных планов



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

Рисунок 3.30 - Результат составления плана

Далее на рисунках 3.31 - 3.37 рассмотрим возможный вариант работы пользователя с подмодулем анализа финансового состояния:

Рисунок 3.31 - Последние загруженные файлы балансов

Рисунок 3.32 - Выбор метода финансового анализа

Рисунок 3.33- Результаты анализа финансового состояния

Рисунок 3.34 - Форма оценки платежеспособности и оборачиваемости ОС, таблица загруженных данных баланса



Рисунок 3.35 - Результаты оценки платежеспособности и оборачиваемости ОС



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

4.1 Краткая характеристика разрабатываемого программного средства

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

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

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

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

4.2 Определение объёма и трудоёмкости ПО

Общий объем ПО рассчитывается по формуле:

(4.1)

где V_i - объем функций ПО;

n - общее число функций.

Параметр объём функций (V_i) определяется по каталогу аналогов ПО, приведенному в таблице 4.1.

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

Таблица 4.1 - Перечень и объем функций программного модуля

№ функции	Наименование	Объём функции (LOC)
		по каталогу	Уточнённый
101	Организация ввода информации	150	150
105	Обработка входного заказа и формирование таблиц	1340	1340
109	Организация ввода-вывода информации в интерактивном режиме	320	320
203	Формирование базы данных	2180	1090
206	Обработка базы данных в интерактивном режиме	6950	2400
207	Манипулирование данными	9550	9550
309	Формирование файла	1020	600
506	Обработка ошибочных и сбойных ситуаций	410	410
507	Обеспечение интерфейса между компонентами	970	970
703	Расчёт показателей	460	560
704	Процессор отчётов	3200	2500
707	Графический вывод результатов	480	480
Итого:		27030	20370

На основании общего объема ПС определяется нормативная трудоемкость Тн ПС. Она определяется по таблице укрупненных норм времени на разработку ПС. Объему (табл. 4.1) условных машинных команд и 2-ой группе сложности соответствует нормативная трудоемкость Тн = 496 чел./дн.

При решении сложных задач для крупных проектов трудоемкость ПС определяется по стадиям разработки: техническое задание - ТЗ, эскизный проект - ЭП, технический проект - ТП, рабочий проект - РП и внедрение - ВН. При этом на основании нормативной трудоемкости рассчитывается общая трудоемкость (То) с учетом распределения ее по стадиям:

(4.2)

где T_O - общая трудоемкость ПС (чел./дн);

T_i - трудоемкость разработки ПС на i-й стадии (чел./дн);

n - количество стадий разработки.

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

T_Уi = T_н · d ст_i · Кс · Кт · Кн , (4.3)

где T_Уi - уточненная трудоемкость разработки ПС на i-й стадии стадии: (технического задания, эскизного проекта, технического проекта, рабочего проекта и внедрения (чел./дн);

T_H - нормативная трудоемкость ПС (чел./дн);

dст_i - удельный вес трудоемкости i-й стадии разработки ПС в общей трудоемкости разработки ПС;

K_C - дополнительный коэффициент сложности ПС;

K_Т - коэффициент использования стандартных модулей;

K_Н - коэффициент новизны ПС.

Удельный вес трудоемкости каждой стадии в общей трудоемкости определим в соответствии с нормативами: d_тз = 0,09; d_эп = 0,07; d_тп = 0,07; d_рп = 0,61; d_вн = 0,16. При этом сумма удельных весов всех стадий в общей трудоемкости равна единице.

Коэффициент использования стандартных для разработки программного продукта соответствует значению К_т = 0,6. Новизне ПО категории В соответствует коэффициент новизны К_н = 0,7.

Уточненная трудоемкость разработки ПС по всем стадиям будет равна:

(4.4)

Результаты расчетов уточненной трудоемкости разработки ПО с учетом стадий приведен в таблице 4.2.

Таблица 4.2 Оценка уточненной трудоемкости сроков разработки

Показатели	Стадии	Итого
	ТЗ	ЭП	ТП	РП	ВН
Коэффициенты удельных весов трудоемкости стадий разработки ПО (d)	0,09	0,07	0,16	0,61	0,16	1,00
Распределение нормативной трудоемкости ПО (Тн) по стадиям, (чел./дн.)	45	35	35	303	79	496
Коэффициент сложности ПО (Кс)	1,06	1,06	1,06	1,06	1,06	-
Коэффициент использования стандартных модулей (Кт)	-	1,0	1,0	0,6	-	-
Коэффициент новизны ПО (Кн)	0,7	0,7	0,7	0,7	0,7	-
Уточненная трудоемкость ПО (Ту), (чел./дн.)	28,39	22,08	22,08	134,70	50,47	278
Сроки разработки (ТР), лет	0,045	0,035	0,035	0,305	0,08	0,5
Численность исполнителей (Чр), чел.	3	2,708	2,708	1,895	2,708	3

На основании уточненной трудоемкости разработки ПС и установленного периода разработки рассчитаем общую плановую численность разработчиков (Чр) по формуле:

(4.5)

где Ч_р - плановая численность разработчиков, чел.;

Ф_эф - годовой эффективный фонд времени одного работника

Т_рд - плановая продолжительность разработки ПС, лет.

Эффективный фонд времени работы одного работника (Ф_эф) рассчитывается по формуле:

Ф_эф = Д_г - Д_п - Д_в - Д_о, (4.6)

где Д_г - количество дней в году, (Д_г = 366 дн.);

Д_п - количество праздничных дней в году, (Д_п = 7 дн.);

Д_о - количество дней отпуска, (Д_о = 21 дн.);

Д_в - количество выходных дней в году, (Д_в = 105 дн.).

Тогда, подставив значения, получим:

Ф_эф = 366 - 7 - 105 - 21 = 233 дн.

Подставим значение в (4.5) с условием, что срок разработки проекта Т_р = 0,5 года (6 месяцев). Тогда плановая численность исполнителей:

чел.



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

? два инженера-программиста II категории ? тарифный разряд ? 12; тарифный коэффициент (Тк) - 2,84; продолжительность участия каждого в разработке ? 89 дн.;

? инженер-программист I категории ? тарифный разряд ? 14; тарифный коэффициент - 3,25; продолжительность участия в разработке ? 100 дн;

4.3 Расчет сметы затрат и цены заказного ПО

Основную заработную плату исполнителей на конкретное ПО (З_О) рассчитывают по формуле:

(4.7)

где n - количество исполнителей на конкретное ПС;

Т_днi - дневная тарифная зарплата i-го исполнителя руб.;

Ф_эi - эффективный фонд рабочего времени i-го исполнителя (дн.);

К_п - коэффициент премий (1,3).

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

(4.8)

где Т_М1 - месячная тарифная ставка 1-го разряда, действующая на предприятии, Т_М1 = 550 000 руб.;

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

Подставив значения в формулу (4.8), получим дневную тарифную ставку для каждого разряда:

( руб.)

( руб.)

Расчёт основной заработной платы исполнителей проекта представлен в таблице 4.3.

Таблица 4.3 - Расчёт основной заработной платы исполнителей проекта

Специалист	Количество разработчиков, (чел.)	Дневная тарифная ставка (руб.)	Продолжительность участия в разработке (дн.)	Основная заработная плата (руб.)
Инженер-программист I-ой категории	1	81250	100	10 562 500
Инженер-программист II -ой категории	2	71000	89	8 214 700
Итого:	3	-	278	26 991 900

Дополнительная заработная плата () определяется следующим образом:

(4.9)

где Н_Д - норматив дополнительной заработной платы (20%).

руб.



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

(4.10)

где Н_СЗ - норматив отчислений в фонд социальной защиты населения и на обязательное страхование (35%).

Расходы по статье «Материалы» (М) определяются по формуле:

(4.11)

где H_МЗ - норма расхода материалов от основной заработной платы (4%).

руб.

Расходы по статье «Машинное время» (Р_М) включают оплату машинного времени, необходимого для разработки и отладки программного средства:

(4.12)

где Ц_м - цена одного машино-часа (6000 руб.);

V_о - общий объем ПС, строк исходного кода;

Н_мв - норматив расхода машинного времени на отладку 100 строк исходного кода (12 машино-часов).

Подставив данные в формулу (4.13), получим величину затрат по статье «Машинное время»:

руб.

Расходы по статье «Прочие затраты» (П_З) на конкретное программное средство определяются по нормативу, разрабатываемому в целом по организации, в процентах к основной заработной плате:

(4.13)

где Н_ПЗ - норматив прочих затрат в целом по организации (20%).

руб.

Затраты по статье «Накладные расходы» (Р_Н), связанные с расходами на общехозяйственные нужды (Р_Н), относятся на конкретное программное средство по нормативу (Н_РН) в процентном отношении к основной заработной плате исполнителей. Норматив устанавливается в целом по организации:

(4.14)

где Н_РН - норматив накладных расходов в целом по организации (40%).

Полная себестоимость разработки ПО (С_п) будет определяться как общая сумма расходов по всем статьям сметы:

С_п = Зо + Зд + Зсз + М + Рм + Пз + Рн (4.15)

С_п = 26 911 000 + 5 398 380 + 11 336 598 + 1 079 676 + 14 666 400 + 5 398 380 + 10 796 760 = 75 668 094 руб

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

(4.16)

где У_РП - уровень рентабельности программного продукта 20%.

15 133 619 руб.

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

(4.17)

Налог на добавленную стоимость (НДС):

(4.18)

где Н_дс - ставка НДС (20%).

Подставив данные в формулу (4.19), получим величину НДС:

НДС = · 20 / 100 =18 160 343 руб.

Прогнозируемая отпускная цена (Ц_о) определяется по формуле:

Ц_оi = Ц_пi + НДС (4.19)

Подставив данные в формулу (4.20), получим :

Ц_о= + 18 160 343 = 130 754 466 руб.

Сведём все расчеты затрат на разработку ПО и его отпускной цены в таблицу 4.4.

Таблица 4.4 - Расчеты затрат на разработку ПО и его отпускной цены

Наименование статей	Обозначение	Значение (руб.)
Основная заработная плата		26 991 900
Дополнительная заработная плата		5 398 380
Отчисления в ФСЗН и на обязательное страхование		11 336 598
Расходы по статье «Материалы»	М	1 079 676
Расходы по статье «Машинное время»		14 666 400
Расходы по статье «Прочие затраты»	Пз	5 398 380
Расходы по статье «Накладные расходы»	РН	10 796 760
Полная себестоимость разработки ПО	Сп	75 668 094
Прибыль от реализации ПО		15 133 619
Прогнозируемая цена ПО без налогов		90 801 713
Отпускная цена ПО		108 962 055

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

(4.20)

где Н_пр - ставка налога на прибыль (Н_пр = 18).

П_ч = 15 133 619 - (15 133 619 • 18) / 100 = 12 409 567 руб.

Таким образом была рассчитана смета затрат на разработку и отпускная цена модуля автоматизации процесса ведения отчетности планово-экономического отдела. Отпускная цена продукта составит 108962055 руб.

При этом исполнитель после уплаты налогов получает от реализации программного продукта чистую прибыль в размере 12 409 567 рублей.

4.4 Определение экономического эффекта от применения разработанного ПС у пользователя

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

В качестве экономического эффекта будет выступать общая экономия всех видов ресурсов за счёт внедрения разработанного программного продукта [17].

Данные для расчета экономии ресурсов приведены в таблице 4.5.

Таблица 4.5 - Исходные данные для расчета капитальных затрат и экономии заказчика от внедрения разработанного ПО

Наименование показателей	Усл. обозн.	Ед. изм.	Значение показателя
			в базовом варианте	в новом варианте
Затраты пользователя на приобретение ПО	Кпр	руб.	-	108 962 055
Среднемесячная зарплата 1 сотрудника	Зсм	руб.	3000000	3000000
Коэффициент начисления на зарплату	Кнз		1,35	1,35
Среднемесячное количество рабочих дней	Др	дн.	21	21
Объем выполненных работ за 1 год	А1, А2	задача	5000	5000
Средняя трудоемкость работ в расчете на одну задачу	Тс1, Тс2	чел-час.	1,5	0,6
Средний расход материалов на 1 задачу	Мт1, Мт2	руб.	350	270
Средний расход машинного времени на 1 задачу	Мв1, Мв2	маш.-часы	0,1	0,07
Продолжительность рабочего дня		час	8	8
Ставка налога на прибыль	Нп	%	18	18
Норма дисконта	Ен		0,36	0,36

(4.21)

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

К_ос - затраты пользователя на освоение ПО, руб;

К_с - затраты пользователя на оплату услуг по сопровождению ПО руб.

Организация-разработчик участвует в освоении ПО и несет соответствующие затраты, на которые составляется смета, оплачиваемая заказчиком по договору. Затраты на освоение определяются по нормативу расходов на освоение (Hoс = 10 %) от себестоимости ПО (таблица 4.4) и рассчитываются по формуле:

(4.22)

где Сп - смета расходов вцелом по организации, руб.

руб..

Затраты на сопровождение и адаптацию ПС (К_c) определяются по нормативу от себестоимости ПО:

(4.23)

где Н_с - норматив расходов на сопровождение и адаптацию (Н_с = 20%).

руб.

Подставив данные из таблицы 4.5 в формулу (4.22), получим общие капитальные затраты заказчика:

К_о = 108 962 055 + 7 566 809 + 15 133 619 = 131 662 484 руб.

Таким образом, заказчик ПО понесёт затраты на приобретение, освоение и сопровождение модуля автоматизации ведения отчетности планово-экономического отдела в размере 131 662 484 рублей.

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

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

(4.24)

где С_зе - экономия затрат на заработную плату при решении задач с использованием нового ПС в расчете на одну задачу, руб.;

А₂ - объем выполненных работ с использованием нового ПС.

Экономия затрат на заработную плату в расчете на одну задачу (C_зе):

(4.25)

где З_см - среднемесячная заработная плата одного программиста, руб.;

Т_с1, Т_с2 - снижение трудоемкости работ в расчете на 100 команд, человеко-часов;

Т_ч - количество часов работы в день, ч.;

Д_р - среднемесячное количество рабочих дней.

Подставив данные из таблицы 4.5 в формулу (4.25), получим:

С_зе= 3 000 000 * (1,5 - 0,6) / (21*8) = 16 071 руб.

Экономия затрат на заработную плату при использовании нового ПС (Сз) составляет:

Сз = 14 535 * 5 000 = 80 357 143 руб.

Экономия с учетом начислений на заработную плату (С_оз):

(4.26)

С_оз = 1,35 * 80 357 143 = 108 482 143 руб.

Экономия затрат на оплату машинного времени (С_м) в расчете на выполненный объем работ в результате применения нового ПС:

(4.27)

где С_ме-экономия затрат на оплату машинного времени при решении задач с использованием нового ПС в расчете на одну задачу.

Экономия затрат на оплату машинного времени в расчете на одну задачу (С_ме):

(4.28)

где Ц_м - цена одного машино-часа работы ЭВМ;

М_в1, М_в2 - средний расход машинного времени в расчете на одну задачу при применении соответственно базового и нового ПС.

Подставив данные из таблицы 4.5 в формулу (4.29), получим:

С_ме= 6 000 * (0,1 - 0,07) = 180 руб.

Экономия затрат на оплату машинного времени на весь объём работ (С_м) составит: