53
6) CAQ/DCAQ
Предприятие будет применять функционал CAQ/DCAQ для того, чтобы
обеспечить учет распределения на текущий день, как части товарно-
материальных запасов магазина. (Рисунок 1 Приложение А)
Продукция, продаваемая фирменными розничными магазинами «РКШВ
», а так же оптовыми представительствами – имеет 2х производителей –
импортное производство (Китай) и собственное (несколько заводов,
расположенных в южном регионе).
Рассмотрим подробнее процесс поставки импортной продукции, включая
технические аспекты (как этот процесс «выглядит на компьютере).
В Китае есть собственный офис фирмы «РКШВ », поэтому опустим этап
согласования выбранных для очередной коллекции наименований продукции и
перейдем к моменту, когда поставщик готов поставить желаемый товар в
нужном количестве (Рисунок 2 Приложение Б)
Слишком много времени и ресурсов тратится на согласование всех
организационных моментов, сбиваются поставки, продукция прибывает не
вовремя, неправильно упакованная, не проверяется на предмет брака. При том
что процесс является достаточно однообразным и отлаженным.
Основные трудности возникают из-за повторных согласований, внесении
изменений, корректировок в распоряжения, впоследствии пропущенных по
причине избыточности информации. Отсутствует структура организации
подобных данных, всё расчеты делаются вручную, согласование производится с
помощью обыкновенной почтовой программы.
Несоответствие входных данных от мерчендайзеров и поставщиков по
причине тех же долгих согласований по конкретной наименовании продукции.
И это при том, что в среднем в коллекции (сезонной) может быть до 250
наименований продукции, из них до 25% импортной (Рисунок 3 Приложение В)
Теперь рассмотрим основные проблемы, возникающие при поступлении
продукции собственного производства на склад.
Несогласованный и несвоевременный процесс обмена данными о
наименовании продукции, её заказе, цветах с отделами, в т.ч. с отделом
allocation, которому необходима эта информация для согласования с другими
отделами (отдел планирования опта и розницы).
54
Далее данные эти поступают от отдела allocation в планирование розницы
для согласования доли для продажи розницы и опта. От планирования розницы
переработанная информация поступает обратно в allocation для расчета
распределений наименовании продукции по региональным представительствам
и центрам. Потом эти распределения отправляются на склад логистам для
подачи конкретных заявок.
Одной из проблем являются корректировки распределений по различным
причинам (корректировка данных от мерчендайзеров, например, неверные
данные по процентовке заказа, корректировка процентов распределения доли
опта и розницы от отдела планирования), так же неправильный расчет
производства по количеству отшитой наименовании продукции. Результатом
всего этого является повторный сбор информации отделом allocation, повторное
согласование распределения.
В числе основных решений перечисленных проблем, обеспечиваемых при
усовии эффективного внедрения рассматриваемой автоматизированной системы
можно назвать следующие.
Во-первых, начиная от мерчендайзеров, данные будут поступать
корректные и вовремя за счет отсутствия многочисленных согласований с
поставщиками сырья, тканей, импортной продукции, т.е. не мерчендайзеры
будут собственноручно составлять карты заказа по каждой наименовании
продукции в корректном виде для allocation и остальных отделов. Данная
информация (карта заказа) будет появляться в программе при утверждении
наименовании продукции и не будет меняться, т.е. allocation не придется
обращаться постоянно к мерчендайзерам за необходимой информацией.
Внесение, утверждение карты заказа будет производиться заранее за счет
актуального обмена информацией.
Так же упростится процесс обмена информацией при расчете норм
упаковок отделом allocation. Все данные для расчета норм упаковок (доля
розницы и опта в процентовке заказа, вместимость данной наименовании
продукции в коробку для упаковки, сертификация по составу с различными
представительствами и остальное) будут поступать в готовом виде в нужное
время к allocation для расчета конечного первоначального распреленеия по
представительствам.
55
Минуя отдел allocation, нужную информацию сможет вовремя получать
отдел планирования опта и розницы, при помощи отдельных инструментов
программы упростится процесс расчета индексов и процентов, необходимых для
расчета планов по каждой категории наименований продукции, т.е. с помощью
внедряемого инструмента мы сможем эффективно распределять товарные
запасы с максимальной гибкостью.
Можно будет менять распределение, чтобы оно отражало меняющиеся
потребности розницы и опта, а также представительства/магазина в
отдельности.
Можно будет более точно рассчитывать индексы и проценты планов
представительств - принимая во внимание прошлые результаты, текущие
тренды, планируемые будущие результаты.
Можно перейти от стратегии распределения «загрузка большей части
товара в начале срока» к стратегии «поступление вовремя».
Необходимо чтоб была возможность скорректировать распределение в
процессе развоза наименовании продукции по представительствам.
Можно сократить загруженность складских помещений, включив
ограничения по вместимости в методологию распределения (Рисунок 4
Приложение Г)
В отличие от обычного распределения ввиде Excel-таблицы с формулами,
прописанными вручную, специалисты смогут оперировать необходимыми
формулами-шаблонами, прописанными в программе, сведя к минимуму
случайные элементарные ошибки, начиная от просто сдвига строчки в таблице,
заканчивая потерей данных в таблицах excel (рис 5 Приложение Д),(рис 6
Приложение Е),(рис 7 Приложение З)
Открывая программу распределения наименовании продукции, мы можем
видеть «срез» наименовании продукции как по цветовой гамме, так по
размерной сетке, и по норме упаковки.
Что является очень удобным вариантом при выборе «точки зрения»
распределения, например, если у нас маленький заказ, представительствам всем
физически не хватает для нормального представления каждого товара, каждо1
наименовании продукции всех размеров в каждом магазине. Любое
распределение, включая все ограничения легко можно отследить по программе,
56
что в таблицах excel создавало большую сложность, т.к. эта информация была
предоставлена не всем отделам из-за сложности представления всей
необходимой всем информации вовремя. Также фактор простой утери такого
объема сложных данных.
Программа же позволяет распределять продукцию по всем нужным
представительствам по всем необходимым условиям, исключая возможность
неосведомленности некоторыми отделами этой информации.
Поскольку, например, при подтверждении распределения, программа
автоматически направляет распределение на склад и в отдел управления
товарными запасами, ставя на контроль процесс развоза наименовании
продукции по данному распределению.
Уменьшится проблема возникновения ошибок ручной работы, т.е.
простого недосмотра о приходящем на склад товаре, о недопроизводстве и
подобном. Ранее возникала проблема распределения вовремя. Т.е. фиксировался
момент прихода наименовании продукции на склад, и в течение короткого
промежутка времени необходимо было сделать распределение, так как
информация поступала недостаточно быстро, то случались частые сбои, ошибки
расчетов, впоследствии корректировки, развоз задерживался на день, на два, что
задерживало соответственно вывод в продажу этой наименовании продукции.
Сейчас эта проблема может решиться тем, что распределение может
делаться еще при утверждении карты заказа на продукцию, и это распределение
не потеряется, даже если производство наименовании продукции начнется через
месяц, а развоз через 8 недель.
Разумеется, за специалистом останется необходимость анализа трендов,
направлений моды, сезонности, каких-то конкретных заказов клиентов
представительств, но то что касается расчетов, чисел, дат прихода,
распределений, процентов – это всё остается за программой.
Это не тот вариант, что останется «нажать одну кнопочку», и программа
всё сделает, но подобная автоматизация процесса существенно упростит
процессы поставок продукции, освободит рабочее время специалистов больше
для анализа наименований продукции, событий, каких-то необходимых данных,
сбора информации.
57
На основании анализа представленных схем графического описания
бизнес-процесс можно сделать вывод о том, что «обмен информацией» между
отделами сократится процентов на 30-40, а может быть даже на 50% за счет
ненужных избыточных согласований департаментов, простоя данных,
непропорциональной загруженности отдельных департаментов, уменьшения
количества ошибок расчетов.
58
3 ОБОСНОВАНИЕ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ
ПРОЕКТА
Для расчета эффективности применяются такие коэффициенты, как:
- Показатель возврата инвестиций (ROI)
- Совокупная стоимость владения (TCO)
- Анализ эффективности затрат (CBA – Cost Benefits Analisis)
Эти коэффициенты не являются независимыми - показатели возврата
инвестиций и эффективности затрат рассчитываются на основе совокупной
стоимости владения системой.
При расчете ТСО учитываются как первоначальные затраты (на
внедрение), так и все последующие затраты (на эксплуатацию, доработку и т. п.).
Недостаток использования этого показателя заключается в том, что он позволяет
оценить лишь расходы на внедрение и эксплуатацию ERP-системы. Поэтому
расчет только ТСО не дает полного представления о целесообразности
использования системы: чем больше пользователей работают в единой системе и
чем сложнее бизнес-процессы, тем выше будет ТСО. Однако и польза от
установки подобной системы будет значительно выше. Поэтому необходимо
учитывать не только затраты, но и выгоды от внедрения ERP-системы, которые
определяются с помощью показателя возврата инвестиций (ROI). Этот
стандартный коэффициент позволяет оценить рентабельность вложений в
покупку и внедрение ERP-системы и рассчитывается по формуле:
ROI = (Прирост доходов – ТСО)
Х 100%
ТСО
Однако многие выгоды от использования ERP-системы на стадии
принятия решения о выборе системы нельзя оценить в количественном
выражении. В таких ситуациях для оценки эффективности внедрения системы
целесообразно проводить анализ выгодности затрат (СВА). СВА основывается
на сравнение двух альтернативных вариантов (без сравнения применять этот
метод не имеет смысла). При оценке предполагаемой эффективности внедрения
59
ERP-системы рассматриваются варианты работы как с использованием системы,
так и без ее применения. При этом подсчитываются возможные потери
(Opportunity Cost) в случае, если проект внедрения не будет реализован.
Индивидуальные показатели эффективности использования
информационной ERP системы.
В зависимости стратегических целей и задач предприятие может выбирать
свои показатели эффективности.
Разработка программного продукта (ПП) разбивается на следующие
этапы:
- "техническое задание (ТЗ)";
- "эскизный проект (ЭП)";
- "технический проект (ТП)";
- "рабочий проект (РП)";
- "внедрение".
Данные стадии разработки программного продукта могут разработчиком
выполняться как полностью, так и в различных комбинациях. На указанные
стадии заказчиком или разработчиком могут накладываться различные
ограничения. В данном случае присутствуют все указанные этапы.
Трудоёмкость разработки программного продукта зависит от степени
новизны разработки, сложности алгоритма её функционирования, объёма
используемой информации и вида её обработки, уровня используемого
алгоритмического языка программирования.
По степени новизны разрабатываемый программный продукт может быть
отнесен к одной из четырех групп:
- Группа новизны «А» - разработка программных комплексов, требующих
использования принципиально новых методов их создания, проведение научно-
исследовательских работ и т. п.
- Группа новизны «Б» - разработка программной продукции, не имеющей
аналогов, в том числе разработка пакетов прикладных программ.
- Группа новизны «В» - разработка программной продукции, имеющей
аналоги;
- Группа новизны «Г» - разработка программной продукции, основанная
на привязке типовых проектных решений.
60
Разработанный программный продукт относиться к группе новизны - «В».
Трудоемкость разработки программной продукции τ может быть
определена как сумма величин трудоемкости выполнения отдельных стадий
разработки программного продукта из формулы (1)
VRPTPEPTZ
,
(1)
где
TZ
– трудоемкость разработки технического задания на создание
программного продукта;
EP
– трудоемкость разработки эскизного проекта программного
продукта;
TP
– трудоемкость разработки технического проекта программного
продукта;
RP
– трудоемкость разработки рабочего проекта программного
продукта;
V
– трудоемкость внедрения разработанного программного продукта.
Трудоемкость разработки технического задания рассчитывается по
формуле (2)
Z
RP
Z
RZTZ
TT
,
(2)
где
Z
RZ
T
– затраты времени разработчика постановки задачи на
разработку технического задания, [чел./дни];
Z
RP
T
– затраты времени разработчика программного обеспечения на
разработку технического задания, [чел./дни].
Их значения рассчитываются по формулам (3) и (4)
Z
RZZ
Z
RZ
KtT
,
(3)
Z
RРZ
Z
RZ
KtT
,
(4)
где
Z
t
– норма времени на разработку технического задания на
программный продукт;
];/[72 дничелt
Z
Z
RZ
K
– коэффициент, учитывающий удельный вес трудоемкости работ,
61
выполняемых разработчиком постановки задачи на стадии технического
задания;
65,0
Z
RZ
K
(совместная разработка с разработчиком программного
обеспечения );
Z
RР
K
– коэффициент, учитывающий удельный вес трудоемкости работ,
выполняемых разработчиком программного обеспечения на стадии
технического задания;
35,0
Z
RР
K
(совместная разработка с разработчиком постановки задач).
Тогда,
]/[72)65,035,0(72 дничел
Трудоемкость разработки эскизного проекта
EP
рассчитывается по
формуле (5)
E
RP
E
RZEP
TT
,
(5)
где
E
RZ
T
– затраты времени разработчика постановки задачи на
разработку эскизного проекта, [чел./дни];
E
RP
T
– затраты времени разработчика программного обеспечения на
разработку эскизного проекта, [чел./дни].
Их значения рассчитываются по формулам (6) и (7)
E
RZE
E
RZ
KtT
,
(6)
E
RPE
E
RP
KtT
,
(7)
где
E
t
– норма времени эскизного проекта на программный продукт. В
нашем случае
];/[112 дничелt
E
E
RZ
K
– коэффициент, учитывающий удельный вес трудоемкости работ,
выполняемых разработчиком постановки задачи на стадии эскизного проекта.
Принимается
7,0
E
RZ
K
(совместная работа с разработчиком программного
обеспечения).
E
RP
K
– коэффициент, учитывающий удельный вес трудоемкости работ,
выполняемых разработчиком программного обеспечения на стадии эскизного
62
проекта. Принимается
3,0
E
RP
K
(совместная работа с разработчиком
постановки задач).
Тогда,
]/[112)7,03,0(112 дничел
EP
Трудоемкость разработки технического проекта
ТР
зависит от
функционального назначения программного продукта, количества
разновидностей форм входной и выходной информации и определяется по
формуле (8)
RV
T
RP
T
RZTP
KKtt
,
(8)
где
T
RZ
t
– норма времени, затрачиваемого на разработку технического
проекта разработчиком постановки задач;
T
RP
t
– норма времени, затрачиваемого на разработку технического
проекта разработчиком программного обеспечения;
R
K
– коэффициент учета режима обработки информации. Принимаем
R
K
=1,45 (группа новизны – В, режим обработки информации – реальный
масштаб времени);
V
K
– коэффициент учета вида используемой информации, определяется
по формуле (9).
Принимается количество разновидностей форм входной информации – 1,
количество разновидностей форм выходной информации – 2:
];/[22 дничелt
T
RZ
];/[9 дничелt
T
RР
BNSP
BBNSNSPP
V
nnn
nKnKnK
K
,
(9)
где
P
K
– коэффициент учета вида используемой информации для
переменной информации;
NS
K
– коэффициент учета вида используемой информации для
нормативно-справочной информации;
B
K
– коэффициент учета вида используемой информации для баз