Реализация бизнес-процессов транспортировки с использованием нон-код платформы «Интеграл» (часть 2)

Подробности

Опубликовано: 27.04.2022 09:00

Автор: Арнаутов Артемий Артурович

Просмотров: 967

Аннотация: для старта проектирования пользуются ранее сформированной картой процесса, которую детализируют до 4-го уровня декомпозиции. Это позволяет определить и спроектировать структуру баз данных, что также исключает необходимость детального моделирования процессов на низком уровне. В завершении дизайна создается макет программы в виде структуры приложения. Для спроектированных сущностей: процессы, данные и структура, выполнена программная реализация, для чего применялась нон-код платформа «Интеграл».
Скачать: PDF (статья), PDF (выпуск №18).
Ключевые слова: автоматизация управления транспортом, система автоматизации транспорта, процесс перевозки, управление процессами перевозок, бизнес процесс транспорта, АРМ перевозчика, автоматизированная система оперативного управления перевозками, автоматизированные системы управления перевозками, проектирование процессов перевозок, автоматизация процессов перевозок.

2. Дизайн информационной системы

Ссылка на 1-ю часть статьи. Типовая идея моделирования программы состоит в том, чтобы разбить ее на как минимум три составляющие: процессы, данные и непосредственно структура приложения [8-9]. Аналогичным образом поступают при построении ИТ-архитектуры в методологиях TOGAF, POSIX, методе Захмана и др. Последуем этому примеру и рассмотрим все требования через призму указанных составляющих.

2.1. Проектирование бизнес-процессов в моделях AS-IS и TO-BE

В ИТ кругах общеизвестным является тот факт, что организационная структура и бизнес-процессы предприятия, задающие бизнес-архитектуру, проектируются в двух базовых моделях: AS-IS и TO-BE. Для моделирования применяют CASE-средства, включающие в себя графические нотации как верхнего (ARIS VACD, IDEF0, BCM), так и нижнего (Cross WFD, BPMN SLD, UML AD, ARIS eEPC, IDE3 и DFD) уровней проектирования [10].

Теперь давайте разберемся, для чего же нужна AS-IS модель. Следуя модели зрелости компании, описывающей необходимость проектирования бизнес-процессов в зависимости от степени ее развития, обосновывается потребность в AS-IS схеме. Именно она позволяет спроектировать текущие подпроцессы и как следствие выявить «узкие места» в работе предприятия [11]. Цена вопроса – трудозатратное проектирование более чем 10 000 операций в выбранной графической нотации. Выполняя реинжиниринг процессов, TO-BE модель призвана исправить найденные недостатки. Однако, в случае внедрений крупных информационных систем типа ERP/ERP2 основной акцент TO-BE модель преимущественно делает на последовательное описание логики выполняемых операций одновременно с детальным разграничением ответственности сотрудников [12]. Следовательно, если принято решение о имплементации ERP-систем, потребность в AS-IS моделировании фактически отпадает.

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

Суммируя все вышесказанное, ограничимся в рамках проектирования лишь доработкой карты бизнес-процессов модели TO-BE. Но и здесь можно сократить объем выполняемых работ: карты процессов AS-IS и TO-BE практически совпадают для операций 1-3 уровней, где степень детализации минимальна. Проработка схемы про-цессов в TO-BE потребуется лишь для уровней 4-е и ниже, хотя на практике даже 3-го уровня детализации бывает достаточно. А чем, собственно, нам поможет карта процессов 4-го уровня? В-первую очередь она используется для проверки того, все ли операции реализованы в программе, во-вторую – подготовки тестовых сценариев приемочных испытаний, и, наконец, – управления изменениями в виде обучения сотрудников.

В ходе проработки бизнес-потребностей операции, отраженные на 3-м уровне карты процессов из таблицы 1.3, были детализированы. Это позволило зафиксировать подпроцессы 4-го уровня, максимально приближенные к исходным требованиям (таблица 1.1.). Результаты обогащения карты процессов на 4-м уровне даны в таблице ниже.

Табл. 2.1. Фрагмент карты процессов в модели TO-BE 

2.2. Моделирование структуры таблиц баз данных

Оптимальным с точки зрения построения структуры баз данных является максимальное использование результатов проектирования. Так, в таблице 2.1 даны операции 4-го уровня детализации. Они сформулированы достаточно четко, чтобы соответствовать идентифицированным требованиям, это позволяет практически однозначно определить объекты хранения данных. Предложим классы данных для проектируемого приложения, а далее уточним их и детализируем на таблицы баз данных, доведя до 3-й нормальной формы. Результаты проделанной работы можно найти в таблицах 2.2-2.3, где под ID подразумевается ключевое поле или составной ключ заданной таблицы.

Табл. 2.2. Классы данных 

Табл. 2.3. Структура таблиц баз данных в 3-й НФ 

2.3. Формирование карты приложения

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

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

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

Рис. 2. Структура разрабатываемого приложения:
а) главное меню; б) формы ввода данных

3. Разработка приложения

В качестве среды реализации приложения выбрана бесплатная нон-код платформа «Интеграл», а также система управления базами данных MySQL, адаптированная под веб разработку. Последовательно велись настройка структуры данных согласно результатам раздела 2.2, а также построение форм ввода данных, описанных в пункте 2.3. Фрагменты полученных программных форм приложения продемонстрированы на рисунках ниже (рис. 3-5).

Рис. 3. Форма создания документов транспортировок

Рис. 4. Форма заведения данных маршрута

Рис. 5. Пример отчета по созданным документам транспортировок

Заключение

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

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

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

Литература 

1. Volition L.X. No-code 101: 270 tools to build websites, apps and software without writing a single line of code. Seven marage. 2022. 301 p.
2. Documents Associated with Business Process Model and Notation Version 2.0 [Электронный ресурс] // Сайт Object Management Group. – Режим доступа: http://www.omg.org/spec/BPMN/2.0/ (дата обращения 10.01.2022).
3. Логистика / Дыбская В.В. и др. – М.: Эксмо, 2009. – 944 с.
4. Новоковский Е.А., Степанов Д.Ю., Шутихина Ю.В. Особенности ведения транспортировок в SAP ERP // Корпоративные информационные системы. – 2019. – №2(6). – С. 39-57. – URL: https://corpinfosys.ru/archive/issue-6/58-2019-6-transport .
5. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
6. О’Лири Д. ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение и эксплуатация / Пер. с англ. Водянова Ю.И. – М.: Вершина, 2004. – 272 с.
7. Степанов Д.Ю. Подготовка функциональных спецификаций для разработки корпоративных информационных систем на примере SAP ERP (часть 1) // Корпоративные информационные системы. – 2019. – №3(7). – С. 29-52. – URL: https://corpinfosys.ru/archive/issue-7/66-2019-7-functionalspec.
8. Петрова Е. А., Фокина Е. А. Информационный менеджмент. – М.: Лань, 2020. – 215 с.
9. Остроух А.В., Суркова Н.Е. Проектирование информационных систем. М.: Лань, 2019. 164 с.
10. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
11. Лодон Дж., Лодон К. Управление информационными системами. / Пер. с англ. под ред. Трутнева Д.Р. – СПб.: Питер, 2005. – 912 с.
12. Олейник П.П. Корпоративные информационные системы: учебник для вузов. - СПб.: Питер, 2012. - 175 с.

Выходные данные статьи

Арнаутов А.А. Реализация бизнес-процессов транспортировки с использованием нон-код платформы «Интеграл» (часть 2) // Корпоративные информационные системы. – 2022. – №2(18). – С. 19-29. – URL: https://corpinfosys.ru/archive/issue-18/198-2022-18-noncodeintegral.

Об авторе

Арнаутов Артемий Артурович – выпускник кафедры корпоративных информационных систем института информационных технологий РТУ МИРЭА. Тема выпускной квалификационной работы магистра «Реализация ключевых бизнес-процессов логистики транспортировки с использованием нон-код платформы». Адрес контактной электронной почты: Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра..

Статьи выпуска №18

1. Учет договоров с использованием HoneyCode (часть 1);
2. Становление корпоративных информационных систем в России;
3. Автоматизация процессов транспортной логистики (часть 2);
4. Стратегия поддержки продуктивного запуска ERP-системы;
5. Импортозамещение в проектах внедрения ERP-систем.