Задание по дисциплине «Корпоративные информационные системы». Осенний семестр 2010-2011 уч. год.
Некоторая компания занимается самостоятельным производством товара. Имеется 3 вида производимых изделий. Существующие производственные мощности позволяют производить в сутки:
Для производства каждого товара необходима комбинация из нескольких (5–7) материалов в различных пропорциях. Часть материалов используется сразу в нескольких изделиях, так что общая номенклатура материалов составляет 12 наименований.
Бизнес сценарий компании выглядит следующим образом.
Клиент обращается к менеджеру из front office и заказывает определенное количество товаров. Менеджер, введя эти данные в информационную систему, получает сведения о возможной ближайшей дате изготовления всей партии товаров. Клиент уточняет срочность заказа (два варианта: стандартный заказ – в течении двух недель от ближайшей даты; срочный заказ – в течение 5 дней от ближайшей даты). Менеджер фиксирует срочность. Заказ считается принятым
Менеджер из back office видит данные по текущим заказам и предложения модуля аналитики по размещению заказов по дням для минимизации простоя с учетом наличия и ожидаемых поставок расходных материалов, на основании этих данных подтверждает предложение или корректирует его. После этого модуль аналитики рассчитывает новую ближайшую дату выполнения нового заказа. Кроме того, менеджер видит предложения модуля аналитики по закупке материалов и также подтверждает или корректирует его. Модуль аналитики должен планировать поставки материалов с учетом того, что материалы могут поставляться оптом один раз в неделю, причем заявка подается за три дня до поставки. С набором статистики по заказам модуль аналитики должен рассчитывать предложения по закупке материалов на ожидаемые заказы, одновременно минимизируя количество материалов, которые закупаются, но не используются до следующей закупки. Производство, при условии наличия необходимых материалов, выполняет заказы с некоторым опережением или отставанием от намеченных сроков и сообщает о выполнении каждой единицы товара в заказе в back office.
Менеджер Front office видит состояние любого заказа и сводку о новых выполненных или задержанных заказах и сообщает об этом клиенту, делая отметку о том, что клиент в курсе состояния заказа. Кроме того, менеджер Front office принимает пожелания клиента по изменению времени выполнения или состава заказа, проверяет возможность этих изменений (информация о разрешении или запрете генерируется автоматически, исходя из текущего состояния заказа) и при наличии возможности изменяет данные заказа.
Разрабатываемая КИС является моделью, позволяющей поддержать описанный бизнес-процесс и протестировать устойчивость как самой КИС, так и бизнес-процесса в целом. В состав системы входит три модуля: модуль, обеспечивающий работу Front office, модуль, обеспечивающий работу Back office и модуль имитационного моделирования. Критерии оценки качества и функциональность модулей представлена ниже.
Критерии оценки качества: интегрируемость с остальными модулями, usability интерфейсов, документация на разработку, пользовательская документация.
Задача: Занести данные о заказе.
Входы – эмуляция заказа от модуля имитации бизнес-процессов (отдельный интерфейс)/пользовательский интерфейс; ближайшая дата выполнения заказа от Back office (БД)).
Выход – данные о принятом заказе в БД.
Задача: получить информацию о новых выполненных заказах или задержках в выполнении заказов, оповестить клиента и сделать отметку об оповещении.
Входы – выборка из БД о выполненных или задержанных заказах, о которых клиент не оповещен.
Выходы – записи в БД об успешном оповещении; отдельный интерфейс модуля имитации бизнес-процессов.
Задача: получить данные о текущем состоянии заказа (состав заказа, дата выполнения, количество выполненных изделий, задержка в выполнении).
Вход – выборка из БД.
Выход – нет.
Задача: выявить возможность изменения параметров заказа (состав и время выполнения) и при наличии возможности внести изменения.
Входы – эмуляция заказа от модуля имитации бизнес-процессов (отдельный интерфейс)/пользовательский интерфейс; выборка из БД о текущем состоянии выполнения позиций заказа.
Выход – записи в БД об изменении в заказах.
Критерии оценки качества: интегрируемость с остальными модулями, устойчивость и эффективность алгоритмов оптимизации, документация на разработку.
Задача: сформировать оптимальный план выполнения заказанных изделий по дням. Критерий – минимизация простоя в день.
Входы – данные о принятых заказах в БД; данные о наличии материалов.
Выходы – БД; отдельный интерфейс модуля имитации бизнес-процессов; пользовательский интерфейс.
Задача: сформировать оптимальную заявку на поставку материалов. Критерий – минимизация количества материалов, не востребованных между поставками, при сохранении бесперебойности работы производства.
Входы – данные о текущих заказах и статистика по прошлым заказам из БД.
Выходы – БД; отдельный интерфейс модуля имитации бизнес-процессов; пользовательский интерфейс.
Задача: занести данные о полученных материалах в БД.
Вход – отдельный интерфейс модуля имитации бизнес-процессов.
Выход: записи в БД.
Критерии оценки качества: интегрируемость с остальными модулями, полнота и эффективность эмуляции параметров бизнес-процессов, полнота и наглядность представления результатов аналитики, документация на разработку.
Задача: сформировать поток заказов с различными распределениями по параметрам.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.
