Бизнес-процессы компании

Оглавление

Введение

Глава 1. Анализ текущей ситуации в организации

Глава 2. Выбор методологии по управлению требованиями

.1 Анализ существующих подходов по управлению требованиями

.2 Определение требований к ИС организации

.3 Определение наиболее релевантной методологии

.4 Пояснения к распределению баллов

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

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

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

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

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

.4 Обработка заказа на закупку товара

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

Заключение

Список литературы

Введение

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

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

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

Задачи, которые должны быть выполнены в рамках данной работы:

—  Проанализировать текущие процессы организации и показать потребности организации, обусловленность внедрения ИС

— Проанализировать уже описанные методологии

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

—  Выбрать наиболее релевантную методологию для организации XXX

—  Обосновать состав требований для организации XXX

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

—  Наблюдение (используется для анализа предприятия XXX)

—  Сравнение (будет использоваться при сравнении различных методик по управлению требованиями)

—  Обобщение (в работе будут приведены примеры различных методик для обоснования выбора наиболее подходящей из них для предприятия ХХХ)

—  Моделирование (будет построена IDEF0 модель для двух уровней и диаграмма вариантов использования для описания текущих бизнес-процессов организации, будет построена диаграмма сценариев использования для анализа функциональных требований)

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

Методики по управлению требованиями ИС перечисленные в данной работе будут получены на основании:

·        Открытых источников (авторы работ перечислены ранее)

·        Личного опыта (будет рассмотрен проект, в котором принималось личное участие)

В итоге работы должны быть получены следующие результаты:

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

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

·        Выявлена наиболее релевантная методология для предприятия XXX

·        Приведен пример разработки требований для предприятия XXX

·        Даны выводы по проделанной работе

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

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

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

·        В первой главе будет проанализирована текущая ситуация в организации, обусловлена необходимость внедрения ИС

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

·        В третьей главе будет приведен пример разработки функциональных требований к ИС для организации ХХХ

·        В заключении подведен итог работы. Проанализирован весь ход исследования и результат работы.

·        В списке литературы перечислены использованные материалы.

Глава 1. Анализ текущей ситуации в организации

Организация ХХХ занимается продажей мебели, начиная с 2002 года. Компания имеет два отделения: первое из которых занимается продажей продукции физическим лицам (в категорию данных продуктов попадают предметы мелкой гарнитуры, как например крючки, подставки, полки и так далее) и юридическим лицам, крупным мебельным магазинам, реализующим свою продукцию в России и в Европе. Работа и правила продажи и закупки для юридических лиц регламентируются специальным документом - «Общее соглашение», которое описывает условия, на которых организация ХХХ и ее партнеры производят совместную хозяйственную деятельность при покупке, продаже товаров и материалов. Продажа продукции физическим лицам происходит через интернет-магазин. Интернет-магазин работает на платформе Magento, которая позволяет обрабатывать заказы клиентов, контент и остатки товаров на складах. Кроме интернет-канала продажа физическим лицам происходит через небольшой магазин в торговом центре. В связи с резко увеличившимся потоком клиентов, как в частном секторе, так и в секторе ритейла организации ХХХ стало очень сложно отслеживать движение товаров и вовремя предоставлять необходимую документацию как при закупке товара, так и при его реализации. Перед руководством компании встал серьезные выбор, между тем, чтобы оставить ситуацию в неизменном состоянии или же попытаться улучшить качество работы предприятия за счет внедрения информационной системы. Другим важным вопросом, в случае внедрения системы, является вопрос о том, какую именно систему нужно внедрить.

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

Для отражения основных функций организации была подготовлена контекстная диаграмма (см. Рисунок 1 Контекстная диаграмма) или первый уровень диаграммы IDEF0.

Рисунок 1. Контекстная диаграмма

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

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

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

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

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

Рисунок 2. IDEF0 Второй уровень

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

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

Рисунок 3 Варианты использования

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

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

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

Глава 2. Выбор методологии по управлению требованиями

.1 Анализ существующих подходов по управлению требованиями

В качестве базовых подходов в данной работе будут рассмотрены три модели по работе с требованиями:

·        Методология RUP

·        Методология Вигерса

·        Методология BABOK

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

Методология RUP

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

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

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

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

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

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

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

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

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

Методология Вигерса

В отличие от методологии RUP, обращающей наибольшее внимание на цикличность операций при работе с требованиями, данная методология приводит намного более подробную декомпозицию требований по различным уровням. Методология делит все требования на функциональные и нефункциональные. К функциональным требованиям относятся требования, которые находятся в рамках функций реализуемой системы, та часть функционала, которая должны быть обязательно выполнена, чтобы пользователи могли работать. К нефункциональным требованиям можно отнести требования, не относящиеся к функционалу напрямую, но тем не менее очень важные для клиента, простота работы с программой, защита информации, которая в ней хранится, устойчивость к сбоям. Работа над проектом, так же как в методологии RUP начинается с определения границ проекта, для чего производится анализ бизнес-требований, требований высшего уровня организации. Эти требования закрепляются в специальном документе - «Документ об образе и границах проекта». Целью данного документа является закрепление исходных требований, на основании которых можно представить, каким образом будет выглядеть система, какими функциями она будет обладать. На следующем этапе происходит более подробное описание системы, ее конкретных функций. Для описания функций нужно построить для каждого пользователя use case диаграмму, которая покажет полный набор функций каждого сотрудника, какими обязанностями и полномочиями он обладает. Это позволяет построить требования на новом уровне, на более глубоком уровне. Понять, что именно требуется от системы в каждом отдельном сценарии и предложить варианты, как это может быть реализовано. Выходом для данного этапа будет документ о вариантах использования, где подробно описаны все возможные сценарии, в этом же документе можно заранее предсказать, какие ошибки система может встретить и как их можно избежать. Дополнительно выделяются системные требования, в данном подходе подчеркивается важность системных требований. Системные требования действительно важны, поскольку именно системные требования определяют, что организация действительно может сделать, а чего она сделать не может. Например, скорость работы программы выделена организацией, как одно из основных требований, но для того чтобы эту скорость обеспечить, нужно поставить отдельный сервер, поскольку на одном терминальном сервере работает одновременно большое количество человек. Организация в данный момент не может обеспечить необходимые системные требования.

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

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

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

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

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

Методология BABOK

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

·        Изменение (процесс трансформации в организации, вызванный существованием потребности)

·        Потребность (проблема, существующая у сотрудников организации, они могут быть как осознанными, так и нет)

·        Решение (способ удовлетворения потребности, конкретный метод)

·        Заинтересованная сторона (сотрудники, являющиеся инициаторами, источниками потребности или сотрудники, занимающиеся внедрением информационной системы)

·        Ценность (положительный эффект, получаемый сторонами при завершении проекта внедрения)

·        Контекст (это вся окружающая среда, которая изменяется при внедрении информационной системы)

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

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

·        Бизнес-требования: дают подробное описание причин начала проекта, зачем происходит внедрение.

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

·        Требования заинтересованных сторон: требования, относящиеся непосредственно к участникам проекта, без выполнения которых невозможно полностью закрыть все требования.

·        Переходные требования: требования, выполнение которых необходимо для перехода от старого бизнес-процесса к новому. Это единственные требования, носящие временный характер, так как их актуальность после завершения проекта теряется.

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

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

·        Бенчмаркинг (сравнение собственных бизнес-процессов с эталонной компанией или группой компаний)

·        Брейнсторм (решение одной задачи усилиями множества людей, при которой каждый сотрудник предлагает свой вариант решения, далее с помощью голосования определяется наилучший вариант)

·        Анализ бизнес-правил (анализ формального окружения организации, базирующегося на существующих регламентах)

·        Игровая манера (предлагает участникам проекта генерировать идеи в игровой форме)

·        Концептуальное моделирование (анализ основных сущностей модели и существующих между ними связей)

·        Исследование интерфейсов (анализ попарного взаимодействия сотрудников, программ, систем)

·        Интервью (анализ требований через ответы на заранее подготовленный список вопросов)

·        Моделирование процессов (построение моделей, описывающих взаимодействие сущностей или последовательность действий процесса)

·        Наблюдение (физическое присутствие на рабочем месте клиента, для описания его деятельности)

·        Опрос (простое анкетирование сотрудников)

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

.2 Определение требований к ИС организации

информационный управление требование

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

·        Точное перечисление участников проекта и их ролей

·        Анализ требований на нескольких уровнях

·        Описание роли аналитика критериев, его роли и компетенций

·        Предъявление наибольшего количества методов для получения требований

·        Возможность построения отчетов

·        Подробное описание распределения усилий на всех этапах проекта

·        Отсутствие необходимости отслеживания изменения критериев в отдельной базе данных

·        Описание требуемого результата при работе с требованиями на каждом этапе проекта

·        Перечисление наибольшего количества описательных диаграмм для моделирования процесса

·        Описание методов отслеживания изменяющихся требований

·        Разбор методов классификации требований по различным уровням

Данный список был получен на основании предварительных переговоров грядущего проекта между продавцом внедряющей организации, представленной в лице группы профессиональных IT специалистов с большим опытом внедрения проектов и компанией ХХХ, заказывающей проект по внедрению информационной системы. После того, как список с требованиями был подготовлен, для достижения наибольшей объективности всем сотрудникам организации ХХХ было предложено пройти тестирование и определить, какие из требований к методологии является наиболее важными. Условия тестирования были следующими, каждый опрашиваемый получил ранее оговоренный список с перечисленными потребностями организации. Среди данных пунктов сотрудник должен был выбрать пять наиболее важных, критичных потребностей для своей организации. При этом пять пунктов нужно было расположить в порядке возрастания потребности организации, первый пункт получал 2 бала, второй- 4, третий - 6, четвертый - 8 и наиболее важный, по мнению интервьюируемого, 10. В результате данного опроса был получен список потребностей организации, который можно считать объективным, так как свои пункты он основывает не на мнении одного человека или группы лиц, а учитывает мнение всех специалистов, работающих в организации. Ниже приведен список с полученными результатами (см. Таблица 1 Критерии выбора методологии")

Таблица 1. Критерии выбора методологии

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

Таблица 2. Веса важности критериев

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

2.3 Определение наиболее релевантной методологии

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

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

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

- Нет данных функций, не отвечает данному требованию.

- Плохо реализовано.

- Удовлетворительно.

- Хорошо.

- Превосходно.

При рассмотрении и сравнении трех методологий, были получены следующие результаты (см. Таблица 3 Оценки методологий)

Таблица 3. Оценки методологий

2.4 Пояснения к распределению баллов

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

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

Подробное описание распределения усилий на всех этапах проекта

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

Описание требуемого результата при работе с требованиями на каждом этапе проекта

Как уже было объяснено ранее, именно методология RUP наиболее подробно рассматривает каждый отдельный этап проекта. Она дает конкретное описание, какие цели ставятся перед каждым этапом и что должно быть выходом проекта. Что имеет наибольшее значение, методология описывает, какой результат требуется получить при работе с требованиями на каждом этапе проекта. Остальные же две методологии также хорошо рассматривают данный аспект вопроса, за что получают оценки, чуть меньшие, а именно по 4 балла.

Описание методов отслеживания изменяющихся требований

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

Разбор методов классификации требований по различным уровням

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

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 Сценарий начинается с того, что клиент, пришедший в магазин организации ХХХ рещается сделать заказ на продажу того или иного товара. Продавец уточняет условия заказа, какие именно товары будут продаваться и в каком количестве. Продавец уточняет согласие и возможность клиента оплатить заказ полностью.

.1 Когда продацец получает от клиента подтверждение заказа, он создает в ИС документ «Заказ» и сохраняет его.

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

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

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

·        Печатная форма (для простых клиентов)

2.5 После печати документа, продавец передают счет клиенту.

.6 Клиент оплачивает заказ. Оплата заказа производится наличными средствами или через терминал по карточке. Данные функции не будут реализованы в системе.

.7 После оплаты заказа клиентом продавец создает в ИС документ «Продажа». Нужно, чтобы данный документ можно было создать в системе копированием из документа Заказ, который был создан ранее.

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

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

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

·        «Товарная накладная» (для простых клиентов)

Данная печатная форма будет передана клиенту.

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

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

Рисунок 6. Продажа юридическому лицу

.0 По договоренности между организацией ХХХ и ее партнерами, заявки на продажу приходят в виде excel файла на почту ответственного по работе с юридическими лицами бухгалтера.

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

.2 При сохранении документ «Заказ» информационная система выполняет автоматическую проверку наличия достаточного количества товара по всем позициям, перечисленным в докуменет «Заказ»

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

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

•        Счет с артикулом, номером и датой реализации (для юр. лиц)

•        Счет с артикулом клиента (для юр. лиц)

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

.6 Покупатель юридическое лицо оплачивает заказ, оплата заказа производится вне информационной системы.

.7 После оплаты юридическим лицом заказа, бухгалтер создает в ИС документ «Продажа». Нужно, чтобы данный документ можно было создать в системе копированием из документа «Заказ», который был создан ранее. Бухгалтер сохраняет документ «Продажа».

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

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

.10 На основании документа «Продажа» должна быть создана печатная форма. При продаже юридическому лицу будут использователься специальные печатные формы:

•        «Торг12 с артикулом» (для юр. лиц)

•        «Торг12 с артикулом-2» (для юр. лиц)

•        «Торг12 с артикулом и договором» (для юр. лиц)

•        «Торг12 с артикулом и магазином (факторинг)» (для юр. лиц)

•        «ТН Факторинг» (для юр. лиц)

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

3.3 Обработка заказа на закупку товара

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

Рисунок 7. Заказ на закупку

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

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

.2 Требуется, чтобы в ИС была реализована возможность преобразования «Заказа на закупку» в виде excel файла. По договоренности с поставщиками, заказ на закупку будет отсылаться поставщикам именно в таком виде.

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

.4 В случае отрицательного ответа, бухгалтер подберет другого поставщика и повторит ранее описанну цепочку действий.

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

.6 Организация ХХХ производит платеж в соответствии с присланным счетом на оплату, в ИС реализовано не будет

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

.8 Создание документа «Закупка» должно автоматически корректировать остатки товаров на складе. При сохранении документа должно происходит увеличение остатков товаров на указанное в закупке количество единиц. Кроме этого должна быть реализованы следующие печатные формы:

·        Торг-12 (товарная накладная за поставщика с услугами)

·        Торг-12 (товарная накладная за поставщика)

·        ОС-14 (акт о приемке оборудования)

·        Приходная накладная

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

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

·        Поступление и списание товара

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

·        Перемещение товара

Поступление и списание товара

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

Рисунок 8. Поступление и списание товара

.0 Офис сообщает по телефону бухгалтеру о необходимости списания товара, реализуется вне ИС

.1 На основании полученных данных бухгалтер создает в ИС документ «Поступление товара» и сохраняет его

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

.0 Так же, как и для поступления товара, списание товара инициирует офис. Офис передают бухгалтеру данные о том, какие товары и в каком количестве нужно списать

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

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

.3 Если данная ошибка появилась, ИС должна показать бухгалтеру предупреждение о том, какого именно товара не хватает и в какой строке документа «Списание товара» данный товар находится.

.4 Если ошибок найдено не было, то документ сохраняется, количество товара на выбранных складах автоматически корректируется в ИС.

Сборка и разборка товара

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

Рисунок 9. Сборка товара

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

.1 На основании полученных данных бухгалтер создает в ИС документ «Сборка» и сохраняет его

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

.3 ИС автоматически должна создать заявку на закупку простого товара, с указанием количества, которого не хватает для сохранения документа. Документ «Сборка» не сохраняется

.4 В случае, если количества простых товаров достаточно, документ «Сборка» сохраняется, ИС автоматически списывает простые товары и приходует составные товары с учетом необходимых количеств.

Рисунок 10. Разборка товара

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

.1 На основании полученных данных бухгалтер создает в ИС документ «Разборка товара» и сохраняет его

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

.3 ИС в случае ошибки не будет сохранять документ «Разборка товара». Бухгалтер сообщит в офис о появившейся ошибке. Ошибка может означать два возможных варианта, либо остатки по инвентаризации являются неверными, либо остатки в системе неверны, что нужно будет исправлять через поступление или списание товара.

.4 В случае, если количества составных товаров достаточно, документ «Разборка товара» сохраняется, ИС автоматически списывает составные товары и приходует простые товары с учетом необходимых количеств.

Перемещение товара

Документ перемещение товара будет использоваться для выравнивания количества товара между различными складами. Подробное описание требований, предъявляемых к системе при реализации данной функции, показано на схеме ниже (Рисунок 11 Перемещение товара):

Рисунок 11. Перемещение товара

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

.1 На основании полученных данных бухгалтер создает в ИС документ «Перемещение» и сохраняет его

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

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

.4 В случае, если количества составных товаров достаточно, документ «Перемещение» сохраняется, ИС автоматически делает списание товара с исходного склада и приходует его на конечном складе.

Заключение

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

Список литературы

1. https://babokpage.wordpress.com //[Электронный ресурс] //URL: https://babokpage.wordpress.com/techniques/data-flow-diagrams/ (Дата обращения 11.01.2017 )

2. Business Analysis in Russia // [Электронный ресурс] //URL: http://iiba.ru/babok/chapters-of-babok-version-3/ (Дата обращения 10.01.2017 )

3. Business Analysis in Russia // [Электронный ресурс] // <http://iiba.ru/>: http://iiba.ru/requirements-analysis/requirements-management-methods/ (Дата обращения 10.01.2017 )

4. Ambler, S.W. (2004). «The Object Primer 3rd Edition: Agile Model Driven Development with UML» 2. New York: Cambridge University Press. www.ambysoft.com/theObjectPrimer.html.

5. <https://www.ibm.com> //[Электронный ресурс] //

URL:https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf (Дата обращения 10.01.2017 )

. Вигерс Карл «Разработка требований к программному обеспечению - М.: Издательсш-торговый дом «Русская Редакция», 2004. -576с.: ил

. Кулябов Д.С., Королькова А.В. Введение в формальные методы описания бизнес-процессов: Учеб. пособие. - М.: РУДН, 2008. - 202 с.: ил.

8. A. Cockbum, Selecting a projects methodology, IEEE Software, 2000

. P. Kruchten, The Rational Unified Process An Introduction Second Edition, USA, 2000

. P. Hruby, Designing customizable methodologies, 2000

. Wiegers, K.E. Software Requirements, 2nd ed. Redmond, WA: Microsoft Press, 2003

. Brackett, J. W. Software Requirements, Software Engineering Institute, Carnegie Mellon University, 1990

. Karlsson, J. & Ryan, K. "A Cost-Value Approach for Prioritizing Requirements." IEEE Software, 1997

. Leffingwell, D. & Widrig, D., Managing Software Requirements: A Use Case Approach, 2nd ed. Boston, MA: Addison-Wesley, 2003

. P. Berander and P. J¨onsson, “Hierarchical cumulative voting (hcv) prioritization of requirements in hierarchies,” International Journal of Software Engineering & Knowledge Engineering, vol. 16, 2006

. J. Karlsson, “Software requirements prioritizing,” in Requirements Engineering, 1996

. T. Saaty, The Analytic Hierarchy Process, Planning, Piority Setting, Resource Allocation. New york: McGraw-Hill, 1980

. J. Karlsson, C. Wohlin, and B. Regnell, “An evaluation of methods for prioritizing software requirements,” Information and Software Technology, vol. 39, 1998

. L. Lehtola and M. Kauppinen, “Empirical evaluation of two requirements prioritization methods in product development projects book series lecture notes in computer science.” Springer Berlin / Heidelberg, 2004

. T. Bebensee, I. van de Weerd, and S. Brinkkemper, “Binary priority list for prioritizing software requirements,” 2010

21. ПОДИНОВСКИЙ В.В. Количественная важность критериев, Автоматика и телемеханика. - 2000

. БАРЫШНИКОВ Ю.М. О среднем числе вариантов, недоминируемых по сравнению В.В. Подиновского, Автоматика и телемеханика. - 1990

. Гафт М.Г. Принятие решений при многих критериях., Знание, 1979

. Миркин Б.Г. Проблема группового выбора, Физматлит, 1974

25. Layna Fisher “BPM Excellence in Practice 2010: Successful Process Implementation”, 2010

. Bizagi Suite “BPMN by example”, 2014

. Michael Blaha, James Rumbaugh “Object-oriented design with UML, second edition”, 2005

. Bran Selic , Garth Gullekson , and Paul T. Ward . Real-Time Object-Oriented Modeling, 1994