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

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

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

Вспомогательные процессы снабжают ресурсами всю деятельность Компании и обеспечивают выполнение основных процессов. На Рисунке 4 представлена карта вспомогательных процессов Компании.

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

2.5 Моделирование процесса учета и прогнозирования объемов продаж

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

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

На Рисунке 5 представлена модель процесса учета и прогнозирования объемов продаж в нотации ВРМЫ.

Рисунок 5 Бизнес-процесс «Учет и прогнозирование*© бъемов продаж» в нотации БРМЫ, модель «как есть»

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

• Ограничение по срокам внесения обновлений и новых данных в Ехсеї- таблицу (максимум в течение 10 дней в начале каждого месяца);

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

• Потеря актуальности данных, внесенных в первые 10 дней месяца, из- за нестабильного спроса клиентов и сезонности бизнеса;

• Повышение сложности сбора и анализа актуальных данных, проверки обновлений и изменений данных в таблицах;

• Отсутствие статистических данных прогнозирования продаж.

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

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

• Минимизировать количество ошибок и погрешностей при прогнозировании;

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

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

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

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

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

На Рисунке 6 представлена модель процесса учета и прогнозирования объемов продаж «как должно быть» в нотации ВРМЫ.

Рисунок 6 Бизнес-процесс «Учет и прогнозирование объемов продаж» в нотации БРМЫ, модель «как должно быть»

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

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

- ID (абсолютная ссылка, уникальный идентификатор требования):

1. Код типа требования с указанием номера требования по порядку в спецификации:

• FU - требования к функциональности;

• US - требования к удобству использования;

• RE - требования к надежности;

• PE - требования к производительности;

• SU - требования к поддерживаемости;

• AR - ограничения.

2. Код проекта и год реализации проекта.

- Статус (обозначение этапа жизненного цикла требования):

• Предложено;

• Одобрено;

• Отклонено;

• Включено.

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

- Приоритет (очередность реализации требований) согласно MoSCoW:

• Must have (MH);

• Should have (SH);

• Could have (CH);

• Won't have (WH).

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

• Критическое (К);

• Важное (В);

• Полезное (П).

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

• Высокая (В);

• Средняя (С);

• Низкая (Н).

- Версия (версия продукта, в которой требование будет реализовано).

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

4. Моделирование информационной системы

4.1 Диаграмма прецедентов

4.2 Спецификация прецедента

Таблица 7 - Спецификация прецедента «Прием отправлений в офисах»

Прецедент: Создание новой комбинации «клиент-продукт»

ГО: 7

Краткое описание:

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

Главные акторы:

Оператор системы

Второстепенные акторы:

Менеджер по ценообразованию и коммерции, клиент

Предусловия:

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

Основной поток:

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

2. Менеджер по ценообразованию и коммерции формирует запрос на создание новой комбинации «клиент-продукт» и направляет этот запрос оператору системы.

3. Оператор системы выполняет регистрацию нового клиента и нового продукта в системе.

4. Система обрабатывает новые данные и сводит их в одну комбинацию.

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

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

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

Постусловия:

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

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

Альтернативные потоки:

Нет

Заключение

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

Глава 1 посвящена инициации и планированию ИТ-проекта: сформирован Устав для проекта по разработке информационной системы; сформирован Реестр рисков проекта; предложен план управления коммуникациями проекта; построена иерархическая структура работ проекта; сформирован лист ресурсов проекта; построена диаграмма Ганта; предложен календарный план проекта.

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

В третьей главе сформированы требования к информационной системе.

Моделирование информационной системы представлено в четвертой главе работы. Построена диаграмма прецедентов, дана спецификация прецедента.

На основе проведенного анализа было принято решение закупить готовое решение для автоматизации процесса учета и прогнозирования объемов продаж. Поскольку основная деятельность Компании в основном реализована на ERP- системе SAP R/3, наиболее подходящим решение с точки зрения реализации и интеграции будет закупка дополнительного модуля программного обеспечения SAP APO (Demand Planning). SAP APO - это независимый компонент, способный взаимодействовать с SAP R/3 через стандартизированные открытые интерфейсы. Компонент Demand Planning - это набор высокопроизводительных средств для усовершенствованного планирования и прогнозирования, позволяющих достичь необходимой скорости реакции на скачкообразные изменения спроса и обеспечить возможность получения прогнозов высокой степени достоверности.

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

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

Бюджет проекта был оценен в 4 000 000 рублей. В эту сумму не входит закупка необходимого ПО, а также работы по внедрению нового продукта. Старт проекта назначен на 01.04.2019. Завершение проекта запланировано до 31.10.2019. Планируемый период с момента инициации до момента завершения проекта составляет около семи месяцев.

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

Список использованной литературы

1. Карл И. Вигерс, Джой Битти. Разработка требований к программному обеспечению. М., 2014

2. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем. Курс лекций. Учебное пособие. ИнтернетУниверситет Информационных технологий. М., 2008.

3. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Методические основы управления ИТ-проектами. Учебник. Москва, 2010. 398 с.

4. Грекул В.И., Коровкина Н.Л., Куприянов Ю.В. Проектирование информационных систем. Практикум. Москва: Национальный открытый университет «ИНТУИТ», 2012. 186 с.

5. Елиферов, В.Г. Бизнес-процессы: Регламентация и управление: Учебник / ЭБС 7КА№ЦМ. -- Москва: ООО "Научно-издательский центр ИНФРА-М", 2015. -- 319 с.

6. Зараменских Е.П. Основы бизнес-информатики: Учебник для бакалавриата и магистратуры. Москва: Юрайт, 2017. 407 с.

7. Зараменских Е.П. Управление жизненным циклом информационных систем: Учебник для академического бакалавриата. Москва: Юрайт, 2017. 431с

8. Информационные системы в экономике: Учебное пособие/ВЗФИ; Под ред. А.Н. Романова, Б.Е. Одинцова. 2-е изд.: доп. И перераб. М.:Вузовский учебник, 2008, 2009, 2010.

9. Селиверстова П.О., Точилкина Т.Е. Методика выполнения учебного реинжиниринга бизнес-процессов для студентов // Экономика и менеджмент инновационных технологий. 2015. № 4.-С. 81-87.

10. Каленов О.Е.: Роль знаний на предприятии: определение, содержание, значение / Вестник Российской экономической академии имени Г.В.Плеханова. 2012 №2

11. Куперштейн В. Microsoft Project 2010 в управлении проектами. СПб: БХВ- Петербург, 2011. 416 с.

12. Олейник, П.П. Корпоративные информационные системы: Учебник для вузов. Стандарт третьего поколения / П.П. Олейник. СПб.: Питер, 2012. 176 c.

13. Песелис А. Управление рисками на предприятии в проектах разработки программного обеспечения / А. Песелис // Предпринимательство. 2012. № 6.

14. Планирование деятельности на предприятии: учебник для бакалавров / под ред. С.Н. Кукушкина, В.Я. Позднякова, Е.С. Васильевой. 2-е изд., перераб. и доп. М.: Издательство Юрайт, 2013. 350 с.

15. Руководство к своду знанию по управлению проектами. Пятое издание. Project Management Institute, Inc, 2013

16. Руководство свода знаний по бизнес-анализу (Руководство BABOK)

17. Федоров, Н.В. Проектирование информационных систем на основе современных CASE-технологий / Н.В. Федоров. М.: МГИУ, 2008. 280 c.

18. Элизабет Халл, Кен Джексон, Джереми Дик. Разработка и управление требованиями. Практическое руководство пользователя. Второе издание. 2005. 240 с.

19. Введение в UML [Электронный ресурс]. Режим доступа: http://www.interface.ru/home.asp?artId=3491

20. Информационный портал [Электронный ресурс] / Бизнесинжиниринговые технологии. Электрон. дан. М., [2014]. Режим доступа: http://www.betec.ru/index.php?id=6&sid=52

21. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием ЦМЬ [Электронный ресурс] / А.В. Леоненков. Режим доступа: www.intuit.ru

Размещено на Allbest.ru