Информация о товаре или услуге, в котором заинтересован заказчик, находится в документации, сопровождающей извещение о проведении закупки. Так как формат документов никак не регламентируется законом, то задача поиска информации о товаре не может быть решена автоматически путем анализа документации. С другой стороны, по мнению автора, она может быть решена для определенных категорий поставщиков, у которых закупочная деятельность связана в основном с каким-либо одним популярным товаром (к примеру, страховым свидетельством или лицензией на программное обеспечение). Именно описание этого товара может быть приведено в первой части заявки.
Таким образом, определив техническую возможность выполнения автоматизации деятельности поставщика по поиску извещений и подаче заявок, можно рассмотреть, как в настоящее время происходит эта деятельность вручную. Первым делом поставщик заходит на сайт какой-либо электронной торговой площадки (для некоторых из которых он также проходит процедуру аутентификации) и переходит в раздел закупок по 44-ФЗ. Далее он, в соответствии с профилем своей деятельности, указывает критерии и ключевые слова для поиска аукционов, в которых он бы хотел участвовать. Затем, в получившейся выборке извещений о проведении электронных аукционов он выбирает интересные ему и переходит в раздел формирования заявки на участие. В форме заявки он указывает данные своей организации, дополняя их документами первой и второй частей. В заключение поставщик публикует заявку начинает ждать результатов рассмотрения первых частей.
1.2 Обзор используемых систем
Среди существующих систем есть экземпляры, которые способны частично выполнять какие-либо действия, предпринимаемые заказчиком перед подачей заявки. Так, среди них наибольшее количество предназначено для поиска закупок по заранее заданным критериям. Одной из наиболее известных аналитических платформ в сфере закупок является «Otc» [5]. Платформа предлагает довольно развитый расширенный поиск закупок по ключевым словам среди нескольких десятков известных электронных торговых площадок, а также по 17 типам процедур и по всем законам, включая 44-ФЗ. В дополнение, у фильтра также имеется возможность указать стоп-слова, предпочитаемый регион, категорию товара по ОКПД2, заказчика, сроки проведения, стоимостные характеристики и некоторые другие данные. Поисковая выборка сопровождается не только основной информацией, указанной в извещениях, но и прогнозами участия, оценкой заказчика и многим другим. Среди недостатков данной системы можно отметить, во-первых, стоимость использования (74900 руб. за год минимум), во-вторых, отсутствие возможности автоматической подачи заявки на участие.
Другим аналогом является система «Стар» [6]. Она, как и предыдущая, имеет развитый поисковой функционал, включающий также поиск по документам. В дополнение система также предлагает возможности поиска будущих закупок путем сканирования план-графиков заказчиков. Как и предыдущая система, «Стар» является платной и обходится каждому пользователю в 5360 руб. Как и «Otc», данная система не предполагает автоматической подачи заявок на участие.
Программная система «My-tender» аналогично рассмотренным ранее системам предлагает своим пользователям расширенный полнотекстовый поиск по закупкам [7]. Интересной особенностью системы является возможность подключения пользователя к рассылке по электронной почте. Подключив рассылку, пользователь сможет получать уведомления об интересных для него закупках. Как и ранее рассмотренные системы, в данной также отсутствует возможность автоматической подачи заявок.
Примером системы, выполняющей также и подачу заявки на участие является «Tenders», разработанная «ssds-team» и находящаяся в свободном доступе на github.com [8]. Так как система представляет собой, по-видимому, исследовательский проект, то она не предназначена для широкого использования. Несмотря возможность подачи заявок, она также имеет несколько недостатков. Первый из них - небольшое число электронных торговых площадок (на момент написания статьи всего две). Второй - поиск информации о закупках через план-графики, что может повлечь необоснованные задержки в сравнении с поиском на электронных площадках.
1.3 Выявление требований к разрабатываемой системе
Основываясь на текущем алгоритме участия поставщиков в торгах, на существующих системах, призванных как-либо автоматизировать работу поставщика, а также на законодательной базе, можно выделить следующие бизнес-требования:
1. Необходимо минимизировать количество рабочего времени, которое тратит поставщик или его сотрудник на поиск закупок и подачу заявок на участие в них, что позволит сократить затраты на персонал, ведущий закупки.
2. Необходимо минимизировать время между появлением извещения о проведении электронного аукциона на электронной торговой площадке и подачей заявки на участие в нем, что позволит получить конкурентное преимущество в случае отсутствия ценовых предложений при проведении процедуры.
Помимо этого, на основании всего вышеизложенного возможно также выделить пользовательские требования для разработки автоматизированной системы подачи заявок.
1. Необходимо хранить информацию о поставщиках, которая включала бы контактные данные поставщика, типовой набор документации для первых и вторых частей заявок, а также набор критериев поиска извещений, соответствующих профилю деятельности организации поставщика.
2. Необходимо хранить информацию об извещениях, опубликованных на нескольких электронных торговых площадках, а также предоставить возможность просматривать её и производить расширенный поиск по ней.
3. Необходимо автоматически формировать и публиковать заявки на участие в электронных аукционах, полученных путем сканирования и соответствующих критериям поиска, указанным в информации о поставщиках.
4. Необходимо оповещать поставщика о найденных системой извещениях о проведении электронных аукционов, соответствующих его критериям поиска.
Помимо пользовательских требований стоит также обозначить системные требования, согласно которым.
1. Программная система должна состоять из подсистем мониторинга электронных торговых площадок, учета данных пользователей и найденных извещений и подачи заявок на участие на электронные торговые площадки, а также обеспечивать постоянное хранение данных и доступ к ним посредством пользовательского интерфейса.
2. Программная система должна обеспечивать обработку и хранение до 10000 извещений в день без видимых задержек.
3. Программная система должна обеспечивать устойчивость к возможным изменениям интерфейсной части электронных торговых площадках.
4. При возникновении сбоев программа должна производить их регистрацию, а также производить попытки восстановления.
5. Надежность программной системы должна быть обеспечена минимальными задержками при восстановлении, а также длительным временем непрерывной работы.
6. Программная система должна быть обеспечена бесперебойным доступом в сеть Интернет с полосой пропускания не менее 64 Кб/сек.
7. Для корректной работы программной системе должны быть доступны 5 Гб ПЗУ и 2 Гб ОЗУ.
На основании всего вышеописанного можно также обозначить функциональные требования к разрабатываемой программной системе
1. Система должна иметь функции создания, редактирования, удаления и просмотра данных поставщика, включающих его контактные данные, документацию для первой и второй частей заявок, электронную почту и набор критериев поиска для извещений.
2. Система должна иметь функции аутентификации на электронной торговой площадке, а также функции скачивания нескольких последних добавленных извещений. Помимо этого, система также должна обеспечивать фильтрацию ранее скачанных извещений. Скачивание должно происходить периодически с заранее заданным интервалом времени.
3. Система должна автоматически сохранять все новые скаченные извещения. Кроме того, при сохранении извещения должна производиться проверка на соответствие извещения критериям поиска какого-либо поставщика. Поставщик должен иметь функцию просмотра всех соответствующих указанным им критериев поиска извещений.
4. Система должна иметь функцию автоматического формирования и публикации заявки на участие в электронном аукционе на электронных торговых площадках. Формирование и публикация должны происходить при положительном результате проверки извещения на соответствие какому-либо поставщику. Публикация должна происходить с использованием данных, указанных поставщиком и от его имени.
5. Система должна иметь функцию автоматического оповещения поставщика по электронный почте в случае положительного результата проверки соответствия извещения какому-либо поставщику.
6. Система должна иметь функцию подтверждения принятия участия поставщика в закупке, если она была опубликована автоматически. Все заявки поставщика, не подтвержденные им через заданный интервал времени, должны быть отозваны автоматически.
Разработанная согласно таким требованиям автоматизированная система позволит избавить поставщиков от ручного поиска извещений, а также формирования заявок для участия в них. Вместо этого поставщики будут получать электронное письмо с предложением принять участие в закупке, соответствующей профилю их деятельности.
Глава 2. Проектирование системы подачи заявок на участие в электронных аукционах
Проект программной системы будет иметь ключевую роль в процессе реализации, поэтому важно изначально разработать его правильно и с достаточной степенью детализации. Проект разрабатываемой программной системы состоит из трех частей: концептуальной, логической и физической.
2.1 Разработка концептуальной модели
Для формирования концептуальной модели программной системы важно в первую очередь проанализировать требования, выявленные ранее, а затем на их основе разработать пользовательские сценарии и диаграмму прецедентов. Кроме того, необходимо также зафиксировать представление о программной системе в динамике, для чего подойдут диаграммы активностей и последовательностей.
Исходя из требований, в системе должны быть реализованы функции для ведения учета данных поставщиков, включающих контактную информацию, документацию для подачи заявок, адрес электронной почты и некоторые другие. В данном случае адрес электронной почты будет уникальным идентификатором поставщика, поэтому для добавления записи о поставщике его адреса электронной почты (наравне с паролем для входа в систему) будет достаточно. Остальная же информация поставщика необходима только для возможности автоматической подачи заявки, поэтому она может быть добавлена позднее, причём самим поставщиком. Таким образом, сценарии для учета пользователей можно разделить на две категории, первая из которых относится к администратору системы (добавление, редактирование и удаление поставщика), а вторая - к поставщику (изменение параметров подачи заявок).
Согласно требованиям, поставщики должны иметь возможность просмотра тех извещений, которые соответствуют указанным ими критериям. Так как критериев поиска извещений для конкретного поставщика может быть несколько, то имеет смысл также реализовать функции учёта для них. Под фильтром можно понимать критерий поиска, записанный в виде строкового выражения, а также его название. Процесс формирования критериев поиска может потребовать некоторые дополнительные умения от пользователя, поэтому логично доверить их администратору. Исходя из этого, у администратора появляются такие пользовательские сценарии, как добавление, редактирование и удаление фильтра.
Для просмотра извещений, соответствующих фильтрам, поставщиками также необходимо сформировать соответствующий сценарий. Помимо этого, для проверки корректности фильтра поставщик должен иметь доступ ко всем извещениям, поэтому необходимо также добавить сценарий для просмотра всех возможных извещений. Из-за того, что их может быть очень много, сценарий можно дополнить поисковыми фильтрами.
Согласно требованиям, система должна иметь возможность автоматической подачи заявок, соответствующим пользовательским фильтрам. Исходя из этого, для поставщиков будет являться актуальным сценарий для просмотра списка поданных заявок. Так как не каждая заявка может подходить под требования поставщика, то необходимо также предусмотреть сценарий для отзыва поданной заявки.
Таким образом, для проектируемой системы было выявлено несколько групп пользовательских сценариев, разделенных в соответствии с ролевой моделью. Все пользовательские сценарии были добавлены в спецификацию [см. Приложение А].
Для формирования диаграммы прецедентов из пользовательских требований было выявлено два актора: администратор и поставщик. Каждый из них был связан с прецедентами, относящимися к ним, при помощи ассоциации.
Администратор, во-первых, получил связь с прецедентом учёта поставщиков, который был расширен с помощью отношения включения за счёт дочерних прецедентов добавления, редактирования и удаления поставщика, во-вторых, был связан с прецедентом учёта фильтров, который подобным же образом был расширен прецедентами добавления, редактирования и удаления фильтров, и, в-третьих, получил связь с прецедентом назначения фильтра поставщику.
Поставщик, в свою очередь, был связан с прецедентами редактирования профиля, просмотра извещений и просмотра заявок. Так как редактирование профиля можно разделить на две части (редактирование настоек профиля, таких, как оповещения, и редактирование данных для подачи заявок), то для каждой из них был также создан свой дочерний прецедент, связанный с родительским отношением включения. Просмотр извещений также был расширен прецедентом просмотра извещений, соответствующим фильтрам поставщика. Кроме того, прецедент просмотра поданных заявок был расширен прецедентом отзыва заявки.