Реализация процесса учета договоров с использованием нон-код платформы HoneyCode и метода Agile Scrum (часть 2)

Подробности

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

Автор: Стаценко Михаил Николаевич

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

Аннотация: в статье ведется автоматизация процесса учета договоров с использованием нон-код платформы HoneyCode и метода Scrum. На начальных спринтах проекта проектируются процессы в нотациях ARIS VACD и BPMN SLD моделей AS-IS и TO-BE, моделируются данные в UML Class Diagram и строится структура приложений. Реализация последующих спринтов позволяет создать каркас программы, обогатить его пользовательскими экранными формами и дополнительными функциональными возможностями.
Скачать: PDF (статья), PDF (выпуск №19).
Ключевые слова: система учета договоров, автоматизация договорной деятельности, автоматизация учета договоров, подсистема управление договорами, no-code платформы, программирование без кода, контрактные системы, пример Scrum, Scrum методология, автоматизация согласования договоров.

3. Нулевой спринт: проектирование процессов, данных и структуры приложения

Ссылка на 1-ю часть статьи. Для проектирования бизнес-процессов был проведён сбор информации о деятельности организации и определён набор критических операций. Более детальное понимание командой разработчиков будущего результата требует графической фиксации процесса учета договоров в моделях «как есть» и «как будет». В данной работе была выбрана нотация ARIS VAСD для описания операций на верхним уровне, низкоуровневое моделирование велось с использованием BPMN SLD.

3.1. Проектирование процессов AS-IS в нотациях ARIS VACD и BPMN SLD

На рисунке 3.1 представлена диаграмма функционирования организации «как есть» в графической нотации ARIS VACD. Продемонстрированные процессы являются основными в деятельности организации. Диаграмма показывает верхнеуровневое представление операций, зону ответственности и данные, с которыми они работают.

Рис. 3.1. Модель уровня управления предприятием в модели «AS-IS»

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

Рис. 3.2. Декомпозиция процесса «Осуществление финансовой деятельности» в модели «AS-IS»

Дальнейшее моделирование процессов будет вестись в нотации BPMN SLD. Рассмотрим результат декомпозиции подпроцесса «Осуществление деятельности по заключению договоров», как наиболее часто встречающегося в рамках финансовой деятельности компании (рис. 3.3). Из схемы можно заметить четыре группы ответственных, имеющих отношение к деятельности по заключению договоров: менеджер по работе с клиентами, юрист, генеральный директор и контрагент. По результатам создаются проект договора и договор. Проект договора является промежуточным документом, с которым происходит работа, и поэтому отражён в рассматриваемой модели. Проект становится договором после подписания с двух сторон.

Рис. 3.3. Декомпозиция процесса «Осуществление деятельности по заключению договоров» в модели «AS-IS»

Деятельность менеджера по работе с клиентами в рамках процесса рис.3.3 заключается в получении информации, такой как: наименование организации, юридическое местонахождение, банковские реквизиты и др., заполнении бланка и печати проекта договора. Для учёта коммерческих договоров ведётся журнал, содержащий статус исполнения договора и сведения о нахождении в архиве. Менеджер по работе с клиентами вносит запись в книгу учёта договоров и снимает копию для передачи на ознакомление непосредственным исполнителям. Можно выделить следующие недостатки текущей организации проекта:

• невозможность оперативного доступа к документам в виду удалённости и обособленности помещения архива;
• упущенную выгоду из-за задержек продления договора в виду отсутствия оповещений о скором окончании договора.

Для более полного описания ключевого процесса учета договоров была подготовлена карта процессов в модели «AS-IS» на рис.3.4. Принимая во внимание карту процессов, перечисленные выше недостатки, возможно разрешить путем разработки приложения с использованием нон-код платформы.

Рис. 3.4. Карта процессов модели AS-IS

3.2. Проектирование процесса «TO-BE» в нотациях ARIS VACD и BPMN SLD

Контекстная модель функционирования организации в модели «как будет» не отличается от процесса, данного на рис. 3.1-3.2. При дальнейшей декомпозиции процесса «Осуществление деятельности по заключению договоров» в BPMN SLD наблюдаются изменения, связанные с использованием разработанного приложения (рис. 3.5).

Рис. 3.5. Декомпозиция процесса «Осуществление деятельности по заключению договоров» в модели TO-BE

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

Рис. 3.6. Карта процессов модели TO-BE

Для лучшей наглядности представления и сравнения моделей «как есть» и «как будет» были созданы карты бизнес-процессов, представленные на рисунках 3.4 и 3.6. При сравнении карт можно заметить значительные изменения в количестве операций из-за добавления разрабатываемого приложения. В ходе проектирования бизнес-процессов в модели TO-BE были отмечены некоторые особенности: после окончания выполнения каждого подпроцесса на третьем уровне, сотруднику необходимо отмечать статус обработки договора.

3.3. Проектирование данных

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

Рис. 3.7. Архитектура данных

3.4. Проектирование структуры приложения

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

Рис. 3.8. Структура приложения

4. Реализация приложения с использованием нон-код платформы

4.1. Первый спринт: разработка каркаса приложения

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

Рис. 4.1. Главное меню

Рис. 4.2. Экран операции «Заключение договора»

4.2. Второй спринт: разработка таблиц баз данных и интерфейсов для оставшихся экранов

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

Рис. 4.3. Экран ведения карточки контрагента

4.4. Четвёртый спринт: добавление функционала фильтрации и поиска

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

Рис. 4.4. Функция поиска

Заключение

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

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

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

Литература

1. Scrum Glossary [Электронный ресурс] // https://www.scrum.org/resources/scrum-glossary (дата обращения 10.04.2021).
2. Cвистунова Ю.В. Современная структура корпоративной информационной системы // Компьютерные технологии в моделировании, управлении и экономике. – 2021. - № 13. – С. 67-70.
3. Larman C., Basili V.R. Iterative and Incremental Development: A Brief History // Computer. – 2003. – vol. 36, №6. – p. 47-56.
4. Основополагающие принципы Agile-манифеста [Электронный ресурс] // Agile Alliance – Режим доступа: http://agilemanifesto.org/iso/ru/principles.html (дата обращения 10.12.2021).
5. Степанов Д.Ю., Вельсовский А.В. Применение Аgile Scrum в проектах SAP // Корпоративные информационные системы. - 2018. - №1. - C. 9-17.
6. Кон М. Agile: оценка и планирование проектов. – М.: Альпина Паблишер, 2019.
7. Магомадов В.С. Платформы low-code и no-code как способ сделать программирование более доступным для широкой общественности // Международный научно-исследовательский журнал. – 2021. – № 6-1(108). – С. 100-103.

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

Стаценко М.Н. Реализация процесса учета договоров с использованием нон-код платформы HoneyCode и метода Agile Scrum (часть 2) // Корпоративные информационные системы. – 2022. – №3 (19) – С. 10-21. – URL: https://corpinfosys.ru/archive/issue-19/196-2022-19-noncodehoneycode.

Об авторе

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

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

1. Единый налоговый платеж и единый налоговый счет в 2023 году;
2. Учет договоров с использованием HoneyCode (часть 2);
3. Контроль качества внедрения и внедренных ERP-систем;
4. Гибридные методы внедрения корпоративных ERP-систем;
5. Формирование ресурсного плана в проектах внедрения ERP-систем.