Файл: Проектирование реализации операций бизнес-процесса «Анализ и изучение конкуренции..pdf

Характеристика существующих бизнес –процессов

Для выполнения моделирования бизнес процессов, строятся полные и непротиворечивые функциональные и информационные модели информационной системы. Эту цель воплощают CASE (Computer Aided Software Engineering) – средства. CASE - технология есть ничто иное как методология проектирования информационных систем. Сюда входит набор инструментальных средств, позволяющих в наглядной форме моделировать процесс, анализировать эту модель на всех этапах разработки и сопровождения системы .

AllFusion ERwin Data Modeler (ранее ERwin) — CASE-средство для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.

AllFusion ERwin Data Modeler (ERwin) предназначен для всех компаний, разрабатывающих и использующих базы данных, для администраторов баз данных, системных аналитиков, проектировщиков баз данных, разработчиков, руководителей проектов. AllFusion ERwin Data Modeler позволяет управлять данными в процессе корпоративных изменений, а также в условиях стремительно изменяющихся технологий.

AllFusion ERwin Data Modeler (ERwin и BPwin) позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusion ERwin Data Modeler упрощает разработку базы данных и автоматизирует множество трудоёмких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Данное решение улучшает коммуникацию организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.

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

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

Человек или оборудование, которые осуществляет операцию, входят в блок снизу и представляются дугой.

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

В работе осуществляется планирование разработки и внедрения информационной системы. Моделирование этого процесса по стандарту IDEF0 проводится следующим образом (рис. 1.2).

Рисунок 1.2 - Общая диаграмма

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

По сути, следующая диаграмма (Рис. 1.3) является моделью жизненного цикла планируемой информационной системы.

Рисунок 1.3 - Декомпозиция общей диаграммы

На выходе с этапа обследования и постановки задачи, при участии персонала исполнителя и заказчика, имеем подписанный договор, утвержденный план-график, техническое задание, а так же готовую рабочую группу для работы над проектом (рис. 1.4).

КПГ и ТЗ становятся регулирующими документами, поэтому по правилам методологии IDEF0 в остальные блоки будут входить сверху, а образованная рабочая группа – снизу, так как будет являться ресурсом.

Рабочая группа в дальнейшем будет участвовать во всех этапах проекта, кроме подэтапа дополнительного обучения персонала, где она расформируется и ресурсом этой функции станет учебный центр НПО «Гефест».

Следующий шаг моделирования – декомпозиция каждого этапа жизненного цикла.

Из диаграммы (Рис. 1.4) видно, что Обследование, и постановка задачи включает в себя:

• Сбор, анализ и согласование требований. Учитываются требования, как заказчика, так и исполнителя;
• Обследование, в ходе которого делаются выводы, соответствует ли требованиям проекта оборудование заказчика и квалификация ключевых пользователей.

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

Рисунок 1.5- Декомпозиция этапа обследования и постановка задач

На этапе «проектирование» (Рис.1.4) в соответствии с техническим заданием создаются физические и логические модели будущей системы, структура базы данных, разрабатываются интерфейсы и безнес-сервисы. На выходе – макет проектируемой системы.

Рисунок 1.5 - Декомпозиция этапа «Проектирование».

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

Рисунок 1.6 - Декомпозиция этапа «Тестирование»

Этап внедрение (Рис. 1.7) характерен отсутствием управляющих элементов «ТЗ» и «Требования к системе» после первого функционального блока, так как система сдана заказчику. Календарный план график и ГОСТ по-прежнему являются управляющими элементами – жизненный цикл системы не закончен.

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

Рисунок 1.7- Декомпозиция этапа «Внедрение»

Обоснование проектных решений по информационному обеспечению

Информационное обеспечение (ИО) предназначено для отражения информации, характеризующей состояние управляемого объекта и являющейся основой для принятия управленческих решений [8].

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

- чрезвычайно большой объем документов для ручной обработки;

- одни и те же показатели часто дублируются в разных документах;

- работа с большим количеством документов отвлекает специалистов от решения непосредственных задач;

- имеются показатели, которые создаются, но не используются.

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

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

1) Входные и выходные документы. Входными документами системы является приходная накладная и накладная на внутреннее перемещение.

Выходными документами являются: журнал прихода, журнал отгрузок, отчет по качеству, отчет по остаткам, отчет по инвентаризации, отчет «Резервы отделов КЦ».

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

2) Экранные формы

Для построения диалога с пользователем возможны следующие способы: диалог типа «Вопрос-ответ»; диалог типа «Меню», диалог на основе экранных форм, диалог на основе командного языка.

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

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

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

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

4) Информационная база. Центральным компонентом информационного обеспечения является информационная база (ИБА), представляющая собой организованную определенным способом совокупность данных, хранимых в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. [1]

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

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

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

Основными способами организации БД являются создание централизованных и распределенных БД. [4] В рассматриваемой задаче не предполагается распределенная структура ИС, т.к. задача небольшая по объему данных и по количеству пользователей.

Обоснование проектных решений по программному обеспечению

Основной особенностью системы «1С:Предприятие» является ее конфигурируемость. Набор объектов, структуры информационных массивов, алгоритмы обработки информации, соответствующих поставленной задаче, определяет конкретная конфигурация. Вместе с конфигурацией система «1С: Предприятие» выступает в качестве уже готового к использованию программного продукта, ориентированного на определенные типы предприятий и классы решаемых задач. Функционирование системы делится на два процесса – конфигурирование (описание модели предметной области средствами систем) и исполнение (обработку данных предметной области). Результатом конфигурирования является Конфигурация, которая представляет собой модель предметной области. Конфигурацией в системе «1С: Предприятие» называется совокупность трех взаимосвязанных составных частей: