,
=
КВт,
Вредоносное ПО (malware) - это назойливые или опасные программы,...
Расчет экономической эффективности является важным шагом при проектировании информационной системы.
Действующей методикой определения экономической эффективности информационной системы установлено, что основным показателем, определяющим экономическую целесообразность затрат на создание информационной системы является годовой экономический эффект.
Хозрасчетным показателем экономической эффективности является коэффициент экономической эффективности капитальных вложений, то есть срок окупаемости.
Экономический эффект рассчитывается по следующей формуле (4.1):
-
годовая экономия;
К – единовременные капитальные затраты на создание и внедрение программы;
-
единовременный нормативный коэффициент
экономической эффективности затрат
(
=0,12….0,15);
-
текущие затраты, связанные с эксплуатацией
информационной системы.
Срок окупаемости капитальных вложений рассчитывается по формуле (4.2)
|
|
где: К – капитальные вложения во внедрение информационной системы;
-
годовая экономия.
Расчет экономического эффекта.
Рассчитаем составляющие формулы – капитальные затраты, текущие затраты, связанные с эксплуатацией информационной систем, годовая экономия.
Чтобы найти К - капитальные затраты на создание и внедрение программы воспользуемся формулой (4.3):
где:
- капитальные затраты на оборудования;
- капитальные
затраты по монтажу.
- себестоимость
разработки программного обеспечения.
Капитальные затраты по монтажу в нашем случае не учитываются.
Необходимо приобрести оборудование и обеспечение. Показатели, используемые при расчетах, предоставлены в таблице 4.1
Таблица 4.1 – Затраты на приобретаемое оборудование и обеспечение.
|
Наименование оборудования и программ |
Количество, шт |
Цена за единицу, тг |
Стоимость, тг. |
Норма амортизации |
Затраты на амортизацию |
|
|
Borland Delphi 7 | ||||||
|
ВСЕГО: | ||||||
Исходя из данных в таблице 4.1, следует, что капитальные затраты составят:
тенге.
Себестоимость разработки программного обеспечения Ср складывается из:
Основной зарплаты инженера-программиста - Зосн (тенге);
Дополнительной зарплаты Здоп (тенге);
Отчислений на социальные нужды Ссоц. нуж . (тенге);
Затрат на электроэнергию Сэ/э (тенге).
Таким образом, себестоимость разработки программного обеспечения рассчитаем по формуле (4.4):
Для расчета Зосн - основной зарплаты инженера – программиста нужно учитывать, что на этапе анализа и проектирования разработкой занимается аналитик. Требуемая квалификация: высшее образование, первая или высшая категория. Разряд единой тарифной сетки, согласно – 14 (тарифный коэффициент 2.25).
На этапе кодирования, тестирования и отладки – инженер-программист. Разряд, согласно единой тарифной сетки, 9 (тарифный коэффициент 1.78). Для выполнения поставленной задачи предприятие выделило аналитика и инженера-программиста в одном лице.
Для данного вида работ используется повременная форма оплаты труда. За основу расчета оплаты труда используем Единую тарифную сетку, в которую вписан весь каталог действующих профессий и должностей по разрядам. Отнесение работников к той или иной квалификационно-должностной группе основывается в сетке на сложности их труда.
Рассчитывается размер должностного оклада по формуле (4.5).
МЗП – минимальная заработная плата (с 01.01.2011 года = 15 999 тнг.);
К тар – тарифный коэффициент, устанавливается в соответствии с ЕТС РК.
Из предыдущих расчетов можно рассчитать почасовую оплату каждого этапа. Постановкой задачи, разработкой алгоритма и структуры базы данных занимается аналитик. Написанием программы, отладкой и подготовкой программной документации - программист. Так как всю работу будет выполнять инженер – программист, то каждый этап будет рассчитываться по часам. Почасовую оплату высчитываем, исходя из того, что на фирме рабочая неделя (5 дней) и 8-часовой рабочий день. Рабочих дней в месяце в среднем 21. Получается 168 рабочих часов в месяц. Отсюда высчитываем оплату за час:
|
тенге/час тенге/час |
Расчет фонда заработной платы представлен в таблице 4.2
Таблица 4.2 – Расчет фонда заработной платы
|
Наименование этапа |
Количество часов, час |
Часовая тарифная ставка, тенге/час. |
Стоимость этапа, тенге |
|
1.постановка задачи | |||
|
2.разработка алгоритма и структуры базы данных | |||
|
3.написание программы | |||
|
4.отладка программы | |||
|
5.подготовка программной документации | |||
|
Дополнительная зарплата (20%) | |||
Отчисления на социальные нужды принимаются в размере 13% от суммы основной и дополнительной зарплат по формуле (4.6):
где, P - мощность, потребляемая компьютером при работе равная 0,45(кВт);
T раб - время работы компьютера (304 часов – написание программы, отладка, составление программной документации);
Ц э - стоимость киловатта электроэнергии на данный момент (9,6 тенге за кВт).
Расход средств на оплату электроэнергии:
Себестоимость разработки программного обеспечения по заработной плате составит 74657,08 тенге.
К - капитальные затраты на создание и внедрение программы по формуле (4.3) составят:
|
|
где: п – количество оборудования;
- номинальная
сущность оборудования (КВт=0,15);
- годовой фонд
времени работы оборудования (2920 часов);
- коэффициент
полезности действия (
).
По ниже приведенной формуле получаем следующее:
где:
- сумма потребляемой энергии:
-
стоимость одного КВт/час (
КВт/час)
Рассчитываем затраты на амортизацию по формуле (4.11):
|
|
где:
-
норма амортизационных отчислений на
оборудование;
-
капитальные затраты на оборудование
Итак, текущие затраты равны:
|
Зтек = 30000 + 30000+ 2943,3 = 62943,3тнг. |
где:
-
затраты на амортизацию используемого
оборудования;
-
затраты на текущий ремонт и обслуживание
оборудования;
-
затраты
на электроэнергию.
Расчет эффективности от внедрения программы.
До внедрения информационной системы на оформление одного заказа затрачивалось 30 минут. После внедрения информационной системы время сократилось на обработку на 10 минут.
Средняя стоимость 1 заявки – 10 058 тн.
Рабочий день менеджера составляет восемь часов, или 480 минут. В день до внедрения программного обеспечения менеджер оформлял:
480/30=16 заявок/день;
После внедрения:
480/20=24 заявки/день;
Рассчитаем разницу в количестве заявок, оформляемых менеджером до внедрения программного обеспечения и после за год.
16*255=4080 заявок/день;
24*255=6 120 заявок/день.
В день после внедрения программного проекта экономия времени составляет:
16*20мин = 320 мин;
480-320=160 мин, или 2,7 часа.
После внедрения у менеджера появилось больше свободного времени, которое он может занять другой работой. Или же, при имеющихся заказах, успеть больше оформить заказов за день.
Рассчитаем экономичность, при условии, если еще в день в среднем оформлять на одну заявку больше.
В году 255 рабочих дней. За год будет выполнено на 255 заявок больше.
Рассчитаем годовую экономию.
Разница в суммах реализации товара составит
255 *10 058=2564790 тн/год;
Примерная рентабельность одного заказа составляет 27%. Годовая экономия составит:
Э год = 2564790 *27% = 692493,3 тн/год;
Срок окупаемости: Т ок. = К/Г эк. = 194 657,08/692493,3 = 0,28, что составляет примерно 3,5 месяца.
Если брать в учет, что заказы прибывают по мере нарастания спроса, то число годовой экономии не является абсолютной величиной. Ведь мы не можем утверждать, что заказы будут всегда, и в свободное время, которое появится у менеджера после внедрения программного продукта, он будет оформлять заказы.
Экономический эффект составит:
|
692493,3 -(194 657,08*0,15+62943,3)= |
Суммарный эффект показывает, за какое время произойдет возмещение затрат на разработку и внедрение информационной системы.
1. Изучить теоретические аспекты и выявить природу «Расчёт экономического эффекта от разработки и внедрения программного продукта»
2. С учетом того что было применен процесс автоматизации в ручную работу среднего работника были извлечены следующие выгоды: процесс поиска необходимой записи стал более экономичным по времени.
Анализируя расчеты экономической эффективности, можно прийти к выводу, что данный проект экономичен, и его внедрение выгодно для предприятия.
У меня есть многолетний опыт внедрения и последующего сопровождения информационных систем на различных предприятиях. Опыт, в большинстве случаев, был успешным – но здесь я хочу побеседовать, в первую очередь, о причинах, ведущих к неудаче в этом деле, предостеречь вас от возможных ошибок. Я означу собственный метод внедрения, который я использовал неоднократно и который помогает избежать большинства из них.
Первая и самая главная причина провала: некорректно поставленная цель для информационной системы .
Это один из основных вопросов для любого проекта вообще. Заказчик зачастую выбирает цель, которая не имеет к информационной системе никакого отношения, или же зависит от нее незначительно. Примеры: увеличение продаж, занятие большей доли рынка, создание другой культуры управления предприятием и т. д. Но если компания производит товар, спрос на который падает – как тут поможет информационная система? Проблему здесь должно решать подразделение маркетинга. Если нужно изменить культуру предприятия – это вопрос управления персоналом и генерального директора. У некоторых, однако, теплится надежда, что стоит отдать деньги за информационную систему - и проблемы, связанные с организаций бизнеса, решатся сами собой. Обещания продавцов, «впаривающих» дорогие, иностранного производства, многократно проверенные и построенные на «лучших мировых бизнес-практиках» системы лишь укрепляют эту веру. Но на деле компания с неэффективным стилем управления останется неэффективной, только уже с информационной системой. Если на вашу продукцию упал спрос, он тоже не изменится никак. Правда, информационная система позволит вам быстро и точно подсчитать убытки, в том числе и от ее внедрения.
Корректно поставленная цель внедрения информационной системы - залог успеха этого внедрения. Правильны цели, связанные с обработкой информации: хранение, поиск данных, задачи, связанные с расчетами, группировкой, анализом. При внедрении системы все это требовать меньше времени. Помните, однако, что ускорение неудачных процессов приведет к еще более неудачному результату для компании, чем было бы без системы.
Вот один из недавних случаев на переговорах с заказчиком. Заказчик хочет сменить систему конфигурирования изделия, надеясь, что это упорядочит работу производства. С его слов, новая система должна предоставить только ограниченный выбор доступных опций изделий. Тогда производству и отделу согласования будет проще работать, появится набор стандартных решений. У заказчика, однако, уже есть конфигуратор. Сразу возник вопрос: зачем менять? Ответ потрясающий: другой конфигуратор «заставит нас работать правильно», создать необходимую документацию на изделие, изменить схемы обработки заказов и скорректировать культуру работы с заказчиком. Получается, менеджеры понимают, в чем проблема, но расписываются в собственном бессилии изменить ситуацию и перекладывают трудности по реорганизации бизнес-процессов на подразделение, которое за это не отвечает. Как правило, такой проект завершается крахом или затягивается на долгие годы.
Даже если предположить, что специалисты-информационщики знают, как следует изменить бизнес-процессы (с логикой у нас порядок), у них все равно нет нужного административного ресурса, да и ожидаемый результат зависит, в первую очередь, не от программного обеспечения. Здесь явно путается следствие и причина. Допустим, есть предприятие А с информационной системой ABC. Предприятие работает стабильно, нет авралов, неразберихи, заказы выполняются в срок, есть планомерная деятельность отлаженного механизма. Можно сделать вывод, что все хорошо благодаря системе ABC, но это 100% не так. Наличие системы ABC у предприятия A, кончено же, вносит свой вклад в бизнес, но не является ключевым. Если руководство некоего предприятия Б решило внедрить у себя систему ABC в надежде, что после ее внедрения предприятие Б тоже будет работать так же, как A, его ждет сюрприз. Деньги будут потрачены, но ожидаемый эффект не наступит, т.к. методика работы на предприятии Б не изменится.
Эффективные цели
Повторюсь – цели, которые я считаю эффективными при внедрении информационной системы, связаны с ускорением существующих бизнес-процессов или созданием новых для обработки данных. Не стоит перекладывать на информационную систему задачи других подразделений, особенно без права влиять на эти процессы.
Внедрение информационной системы позволяет запустить бизнес-процессы, которые прежде не имели права на существование из-за неприемлемых сроков выполнения. Более того, я считаю, что запуск новых бизнес-процессов - обязательное условие для успешного внедрения системы. Очевидно, если раньше мы использовали напильник для выполнения работ, а теперь у нас станок, это будет другой процесс. Если планирование было налажено плохо, станок, из-за своей производительности, принесет компании еще больший убыток.
Итак, с целями мы определились, теперь осталось правильно составить техническое задание.
Техническое задание
Это вторая по важности составляющая успеха при внедрении информационной системы. Напомню, эффективная цель – ускорение бизнес процессов, которых может быть еще не существует. Заказчик только в общих чертах понимает, что ему нужно. Хорошим вариантом считается уже на первых этапах работы составить подробное многостраничное ТЗ. Это работает, особенно для исполнителя по контракту. Заказчик все подписывает, не до конца понимая, что именно сделает исполнитель. А между тем, за каждое новое поле или форму, не записанные в ТЗ, исполнитель запросто попросит с заказчика еще денег. В итоге заказчик получит процесс с неполными или избыточными данными, хотя формально контракт был выполнен в точном соответствии с требованием. Заказчик будет недоволен и во второй раз к этому исполнителю не обратится.
Получается, что не заказчик подписал неподходящее ТЗ, а исполнитель разработал и предложил совсем не то – не угадал, о чем мечтал заказчик. Замечаете парадокс? Исполнитель сам для себя пишет ТЗ, но при этом должен угадать, чего на самом деле хочет заказчик. В принципе, это возможно (для участников шоу «Битва Экстрасенсов»), но маловероятно. У меня был опыт создания подробных ТЗ, которые на этапе внедрения претерпевали изменения порядка 30%. Обычная история: в процессе работы над проектом у заказчика появлялись новые идеи, их приходилось учитывать, отказываясь от предыдущих решений. Потому я не сторонник очень подробных ТЗ. Они отнимают много времени, а в итоге будут скорректированы на этапе опытной эксплуатации и внедрения. Если не сделать корректировку, можно испортить отношения с заказчиком. При попытке сослаться на подробное ТЗ в ответ вы услышите – «ну, вы же специалисты, должны были сами все знать заранее».
Я считаю, в ТЗ должны быть отражены только общие блоки работ с описанием ожидаемых результатов. Пусть оно достаточно точно описывает, что хочет получить заказчик, и что должен сделать исполнитель. Корректировка ТЗ неизбежна из-за того, что при появлении нового инструмента у заказчика обязательно появятся новые бизнес-процессы. Попытка сохранить прежние бизнес-процессы приведет к провалу проекта. Конечно, не все старое отметается полностью, оно корректируется в соответствии с возросшими возможностями предприятия при наличии информационной системы. Максимум, на чем должно останавливаться ТЗ – списки документов для обработки системой с их образцами. Таким образом, составленное ТЗ не изменится по части общих требований, фактически оно будет уточняться в процессе внедрения, вплоть до конкретных полей и процессов. При этом исполнитель в любом случае знает ожидаемый объем работ. Для успешного проекта требуется 1-2 итерации: внедряется определенный объем выполненных работ, и по результатам заказчик согласовывает коррекцию с исполнителем. Время, которое можно было потратить на излишнюю детализацию ТЗ, гораздо эффективнее использовать для итерационных корректировок системы в соответствии с результатом тестовой эксплуатации.
Есть еще один вариант составления ТЗ: в нем декларируется конечная цель заказчика. И тут вы можете сразу заметить противоречия с предыдущем написанным тестом. Это случай составления проекта, в котором информационная система является только частью. У меня был опыт внедрения комплексной системы управления компаний, где основная сумма по контакту выплачивалась в случае, если заказчик получит увеличение оборота в два раза. Спрашивается, это как? Ответ прост: цели заказчика - автоматизация и оптимизация бизнес процессов копании, ускорение процесса работы с клиентами, точный учет затрат по контрактам, точный расчет бонусов менеджерам, участвующим в контрактах, финансовое планирование. Исходя из того, что все эти задачи не были решены, я подписал контракт. К сожалению, достигнуть 100% увеличения объема оборота у заказчика за 1 год не удалось, но 83% тоже хорошо. Мое вознаграждение было выплачено пропорционально.
Следующим важным документом для успешного выполнения работ является план-график работ.
План-график работ
План-график - документ, содержащий план конкретных работ, в котором описаны действия, которые должны выполнить как заказчик , так и исполнитель . План-график нужен для оперативного контроля за работой обеих сторон. Как правило, в нем перечисляются все системы и подсистемы со своими процессами, документами, отчетами, которые будут разработаны и внедрены. К примеру: действия заказчика, связанные с организацией рабочих мест, прокладкой коммуникаций, обучением персонала и т.д. На каждом пункте плана-графика может быть проставлена цена и длительность, это дает возможность делать взаиморасчеты между исполнителем и заказчиком. Работы, конечно, могут идти параллельно. Хорошо использовать диаграммы Ганта или что-то аналогичное, но не обязательно.
Запуск системы в работу
Запуску системы предшествует тестирование исполнителем системы на примерах заказчика. После получения положительных результатов начинается работа по реальному внедрению и запуску системы. Если опытная эксплуатация делается только на опытных примерах без участия рядовых исполнителей заказчика, без использования реальных задач, она не достигнет поставленной цели. Целью же является сбор замечаний, которые необходимо устранить для перевода в промышленную эксплуатацию. Данный этап правильнее было бы назвать расширенным тестированием с привлечением исполнителей заказчика. Реальная опытная эксплуатация начинается после внедрения системы при участии, как минимум, 50-70% процентах рабочих мест.
Персонал проходит обучение, для пользователей составляются краткие инструкции. Этот этап может длиться от нескольких минут до нескольких недель. Хорошо работают методы экстремального программирования, когда поступившие замечания от сотрудников исполнителя сразу устраняются квалифицированными разработчиками заказчика, желательно на месте у заказчика. Тем самым за одну, максимум две недели можно решить основную массу проблем, связанных с запуском и адаптацией системы. Без масштабного запуска с неукоснительным требованием руководства заказчика введение в эксплуатацию может затягиваться на долгие месяцы. Если нет жесткого требования руководства, люди будут работать по-старому. При любых нововведениях у людей лишь возникнет ощущение, что им кто-то мешает жить.
После этапа опытной эксплуатации сразу следует промышленная. Отличие между ними только в количестве замечаний, которые должны быть устранены, и в отсутствии критических проблем, при наличии которых эксплуатация становится невозможной.
В итоге мы получаем такие этапы запуска и внедрения системы:
- Тестирование с привлечением сотрудников заказчика на реальных примерах;
- Опытная эксплуатация с немедленным устраняем возникающих проблем;
- Промышленная эксплуатация.
Этот метод был проверен мной многократно на предприятиях различных масштабов. Сотрудники компании заказчика в некоторые моменты испытывают дискомфорт, как и сотрудники исполнителя. Но, к счастью, дискомфорт этот быстро сходит на нет, и предприятие переходит в планомерную работу при конструктивном подходе к решению возникающих задач.
Теги: Добавить метки
Система управления трудовыми ресурсами – это программное обеспечение, которое призвано реализовать выбранную фирмой стратегию планирования распределения сотрудников по проектам, задачам и поручениям на практике.
Зачем нужна система управления ресурсами
Главные цели, которые преследует внедрение подобной системы, сводятся к следующему:- Оценка соответствия количества имеющихся работников и текущего спектра задач.
- Распределение задач между сотрудниками оптимальным образом, чтобы каждый занимался своим делом.
- Контроль скорости обработки конкретных задач. Самый важный параметр, потому что от него зависит деловая репутация фирмы и взаимоотношения с клиентами.
- Контроль эффективности труда каждого отдельного работника.
Как оценить эффективность системы управления ресурсами
В идеале эффект внедрения системы управления человеческими ресурсами должен сводиться к ускорению работы предприятия и увеличению прозрачности всех происходящих процессов. Если деловая репутация компании улучшилась, клиенты и партнёры стали более довольными, а руководитель получил возможность видеть полную картину без лишних усилий, то можно говорить про успешное внедрение.Но на практике руководство предприятий, использующих систему управления ресурсами, часто сталкивается со следующими проблемами:
- Оценить эффективность системы управления ресурсами “в чистом виде” сложно, потому что она неотделима от других составляющих бизнеса.
- Внедрение затягивается на длительный срок, а настройка и оптимизация такой системы – бесконечный процесс.
- Эффективность внедрения системы управления трудовымии ресурсами неотделима также от человеческого фактора: от того, насколько сотрудники предприятия заинтересованы в использовании возможностей нового программного продукта. Если внедрение системы произошло “по указке сверху”, когда реальной заинтересованности в её применении у сотрудников нет, то не стоит удивляться низкой эффективности.
Важнейшими принципами при использовании системы для организации являются:
- Соответствие затрат результату. Внедрение дорогостоящего продукта “для галочки” – большая ошибка.
- Отведение системе должного места в структуре предприятия. Оно не должно быть ни слишком маленьким (внедрили, но не пользуемся), ни слишком большим (главный навык работника – умение пользоваться системой).
Затраты на внедрение системы управления ресурсами
Сколько стоит внедрение системы? Такой вопрос руководитель всегда задаёт разработчикам, но часто слышит в ответ совсем не ту сумму, которую придётся потратить. И дело не в том, что разработчики намеренно вводят в заблуждение, а в том, что затраты собственно на внедрение – сравнительно небольшая часть суммарных затрат, верхушка айсберга, так как ещё придётся потратиться на:- Поддержание работы системы. Часто требуется создать целый отдел предприятия, который будет заниматься только этим, а это для фирмы пожизненная ежемесячная выплата зарплаты нескольким сотрудникам.
- Обучение персонала. Также не может быть достигнуто проведением разового курса лекций. По мере изменений системы потребуется давать новую информацию всем сотрудникам, а если они меняются или перемещаются, то проводить дополнительные инструктажи.
- Оптимизацию бизнес-процессов под систему управления ресурсами. Даже если не идти фанатично по пути приведения всего в соответствие с системой, работа по новым принципам всё равно потребует пересмотреть все этапы постановки задач и их отслеживания, составления документов и их согласования. По сути, в этом изменении и состоит цель внедрения, но применение таких принципов на практике может оказаться сложным для работников предприятия.
- Только они обладают навыками для внесения изменений
- Перестать им платить нельзя, потому что иначе система не будет работать.
- Отказаться от системы тоже нельзя, ведь компания уже частично интегрировала её в свои бизнес-процессы.
Альтернатива дорогостоящим системам управления ресурсами
на базе Comindware Business Application Platform – больше, чем система управления ресурсами в классическом понимании. За счёт этого оно не имеет тех недостатков, которые неотделимы от таких систем. Преимущества системы состоят в том, что:- Она помогает эффективно распределять ресурсы предприятия, создавать и отслеживать задания для сотрудников, расставлять приоритеты, не допускать конфликта ресурсов.
- Система помогает спланировать самые важные задачи и спрогнозировать трудности, которые возникнут.
- “Рабочей единицей” системы является бизнес-процесс. Она помогает контролировать его от момента создания до момента завершения, учитывая всех сотрудников и все документы, относящиеся к данному процессу.
- Интегрирована с Active Directlry.
- ERP (системы управления ресурсами)
- BPM (системы управления бизнес-процессами)
- ACM (система управления кейсами и задачами)
Когда проводится оценка эффективности системы управления человеческими ресурсами, за основу берётся тезис, что эффективность – это отношение достигнутого результата к понесённым затратам. При использовании Comindware Business Application Platform эффективность оказывается высокой и за счёт хорошего значения первого параметра, и в особенности благодаря низкому значению второго.
Если вы никогда не пользовались системой управления ресурсами или недовольны той, что имеется, закажите демонстрацию возможностей системы на базе Comindware Business Application Platform. Это бесплатно.
Елена Гайдукова, маркетолог-аналитик, бренд-менеджер решений на базе , специалист по партнёрским отношениям.
