Материал: Бизнес-процессы компании

2.5 Выбор методологии для работы с требованиями

Рассматривая все полученные результаты по каждой из перечисленных методологий, можно сказать, что ни одна из методологий не является однозначно доминирующей или доминируемой. Это действительно так, потому что, например, методология BABOK, которая получила наименьший балл во втором и четвертом критерии, набрала максимальный балл в первом критерии. Для методологии RUP можно сделать схожее наблюдение- во втором и третьем критерии данная методология получила наибольший результат, показав более посредственные значения в четвертом критерии. Для методологии Вигерса так же заметна тенденция разницы в показываемых результатах. В данном случае, для разрешения вопроса о том, какая из методологий является наиболее релевантной для организации ХХХ, нужно использовать метод Подиновского, так как данная задача является классической многокритериальной задачей.

Для решения задачи и выявления наиболее подходящей методологии, нужно использовать важность каждого критерия, так как однозначно доминирующей методологии на данном этапе нет. Вес каждого критерия определился на основании анкетирования, проведенного в первой части работы. На основании полученных весов критериев можно утверждать, что первый критерий является условно в три раза более важным, чем пятый критерий. Первый критерий примерно в два раза важнее второго критерия. Второй, третий и четвертый критерии можно условно считать равно важными. Для того, чтобы учесть относительную важность всех критериев, было принято решение расширить исходную таблицу так, чтобы каждый из пяти критериев попал в таблицу столько раз, на сколько важным он является относительно других критериев. Исходя из данной логики, если пятый критерий используется в таблице два раза, то первый критерий, который оказался примерно в три раза важнее пятого, будет использован десять раз. Соответственно, второй, третий и четвертый критерии, будут использованы в таблице по пять раз, так как они примерно в два раза менее важные чем первый критерий. При расширении таблицы были получены следующие результаты (см. Таблица 4 Распределение оценок с учетом важности критериев)

Таблица 4 Распределение оценок с учетом важности критериев

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

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

Глава 3. Разработка требований к ИС организации ХХХ

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

Методология Виггерса декомпозирует все требования на функциональные и нефункциональные. Так как данная работа фокусируется только на функциональных требованиях, мы не будем рассматривать нефункциональные требования. Источником для функциональных требований станет анализ бизнес-процессов организации ХХХ. В первой главе данной работы было дано подробное описание текущей ситуации на предприятии. Данная глава подчеркнула необходимость внедрения информационной системы. Кроме этого, контекстная диаграмма IDEF0 и диаграмма вариантов использования объяснила, какие бизнес-требования стоят перед системой, какие основные процессы она должна автоматизировать, а именно:

·        Процесс закупки товара

·        Процесс продажи товара

·        Операции по складу

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

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

·        Обработка документа заказа, выгруженного из системы Magento

·        Обработка заказа на продажу в магазине

·        Обработка заказа на продажу юридическому лицу

·        Обработка поступления товара

·        Обработка списания товара

·        Обработка сборки товара

·        Обработка разборки товара

·        Обработка перемещения товара

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

3.1 Обработка документа заказа, выгруженного из системы Magento

В данном случае рассматривается сценарий, при котором заказ оформляется клиентом на сайте, но документация готовится в ИС (см. Рисунок 4 Заказ из системы Magento)

Рисунок 4. Заказ из системы Magento

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

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

.1 Оператор интернет-магазина получает уведомление о наличии нового заказа с указанием номера заказа, даты и времени получения, данные о покупателе. Данные функции уже на данный момент реализованы в системе, они останутся без изменений.

.2 Оператор находит данный заказ в системе Magento, проверяет правильность введенных данных. Оператор смотрит, чтобы в заказе были проставлены правильные артикулы товаров с правильными ценами. Система Magento уже позволяет оператору выполнить данные действия, никаких изменений в текущем бизнес-процессе на данном этапе не будет.

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

.4 Если все данные изначально введены корректно, то оператор сразу подтверждает заказ. Заказ переводится в режим «В ожидании». Данная функция уже реализована в системе Magento

.5 При моем непосредственном участии в совещании с представителями компании, отвечающей за техническую поддержку системы Magento, нами было выяснено, что система может формировать xml файл, содержащий информацию о заказе, а именно основную информацию о заказчике, дате заказа, выбранного способа оплаты, данные о доставке и дополнительную информацию о том, какие именно товары были заказаны, в каком количестве и по какой цене. Соответственно, от ИС требуется, чтобы она имела возможность формировать документ «Заказ» на основании выгружаемого пакета. При этом, все данные документа должны корректно заноситься в соответствующие строки. Выгрузка будет запускаться с помощью специальной службы, которая через равные интервалы времени будет проверять папку-источник на наличие новых пакетов заказов и автоматически выгружать данный документ в ИС (рекомендуемый интервал выгрузки, предложенный со стороны поддержки сотрудников Magento, составляет пять минут).

.6 После того, как заказ будет выгружен в ИС, бухгалтер проверит корректность выгруженных данных.

.7 В первую очередь, бухгалтер должен проверить правильность отображения артикулов товаров, их количеств и данных по ценам. Особое внимание при проверке цен нужно будет уделить скидочным товарам. В том случае, если какие-то из перечисленных данных будут отображены неверно, бухгалтер должен отменить заказ, в документе заказа нужно реализовать поле, в котором бухгалтер сможет указать причину отказа. При отмене заказа ИС должна сформировать ответный пакет xml, в котором будет указано, какой именно заказ был отменен и по какой причине. Оператор Magento получит уведомление о том, что один из заказов был отменен с указанием причины отмены, свяжется с клиентом и уточнит детали заказа.

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

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

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

.11 Вне зависимости от того, достаточно ли в данный момент всех позиций в заказе на складе ИС должна сформировать счет, в котором будут перечислены данные заказа с указанием всех позиций товара, их количества и стоимости

.12 Клиент производит оплату заказа, ИС в данном процессе участие не принимает.

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

.14 В том случае, если сумма, внесенная пользователем, отличается от суммы, заявленной по счету, оператор интернет магазина связывается с клиентом и уточняет условия заказа. Если произошла ошибка отменяет в ИС заказ и вся цепочка повторяется заново.

.15 Если все данные заказа были внесены верно, то бухгалтер создает продажу на основании заказа. От ИС требуется, чтобы была возможность создать продажу копированием из заказа. В противном случае бухгалтеру нужно будет заново вносить все данные заказа, что может вызвать большое количество ошибок. Бухгалтер сохраняет документ продажа в ИС.

.16 В момент сохранения документа продажа ИС должна выполнить списание всех перечисленных в документе «Продажа» позиций со склада. Количество списываемых позиций товаров должно полностью соответствовать количеству в документе. ИС должна сгенерировать пакет xml с указанием, какие товары и в каком количестве должны быть списаны. Данный пакет будет загружен в систему Magento и изменит в ней остатки по нужным позициям.

.17 На основании документа Продажа ИС должна сформировать для покупателя письмо, в котором будут перечислены данные об успешном завершении сделки, указанием количества проданного товара, цен проданного товара.

.18 На основании документа «Продажа» ИС система должна отправить данные на фискальный регистратор для последующей отправки в налоговую службу. Это необходимо в связи с наличием Федерального закона от 03.07.2016 N 290-ФЗ "О внесении изменений в Федеральный закон "О применении контрольно-кассовой техники при осуществлении наличных денежных расчетов и (или) расчетов с использованием платежных карт" и отдельные законодательные акты Российской Федерации"). Для исполнения данного закона организацией ХХХ был приобретён специальный фискальный аппарат, который может отправлять данные о каждой продаже в налоговую службу. Следовательно, внедряемая система должна быть способна отправлять данные о продаже на фискальный аппарат, чтобы он мог формировать отчетность по НДС. Фискальный аппарат, также принимает на вход xml файл. Таким образом, при сохранении документа «Продажа» ИС будет формировать xml пакет данных, содержащий информацию о продаже и НДС.

3.2 Обработка заказа на продажу физическому лицу в магазине

В случае с обработкой заказа в магазине, исполнителем является продавец в магазине, в отличие от первого сценария вся работа будет происходить только в ИС системе, и интеграция будет затрагивать только выверку остатков между ИС системой и системой Magento. Графическое описание данного сценария работы приводится ниже (Рисунок 5 Заказ в магазине)

Рисунок 5. Заказ в магазине

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