Файл: Проектирование реализации операций бизнес-процесса "Планирование закупок и размещение заказов поставщикам.pdf

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

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

В иерархической модели каждой информационной единице (сегменту), кроме корневого, соответствует один исходный сегмент и между ними создается лишь одна связь. В таких моделях экземпляру исходного сегмента соответствует в общем случае определенное количество экземпляров порожденного сегмента. Данные структуры удобны для отображения отношений типа «один ко многим» в предметной области. Обзор такой структуры имеет место быть лишь с корневой вершины. Пропуск сегмента в иерархическом пути при доступе к определенному сегменту не позволяется [8, c.65]. Ключевые недостатки иерархической структуры: сложность (неэффективность) отображения отношений типа «многие ко многим»; долгое время обеспечения доступа к сегментам, состоящих на нижних уровнях иерархии; направленность на некоторый тип (разрез) запроса.

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

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

Достоинства применения реляционных БД следующие:

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

- теоретическое обоснование – присутствие теоретически аргументированных методов нормализации отношений дает возможность получать БД с заранее установленными свойствами (прежде всего, с гарантией наименьшей избыточности отображения данных);

- независимость данных – когда нужно изменить структуру БД, то это ведет к минимальным изменениям в программе [27, c.15].

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

Исходные данные для выполнения установленной задачи получают из таких документов, как:

- e-mail от работника фирмы с описанием проблемы на неформальном языке в ИТ-области;

- регламент работы службы горячей линии;

- ежедневное письмо о нахождении работников ИТ-отдела по всем направлениям;

- письма, определяющие изменения ответственных лиц по установленным направлениям инцидентам и новым направлениям [6, c.55].

Результаты выполнения задачи видны в таких отчетах и документах, как:

- отчет по согласованным заказам;

- отчет заказов по местоположению клиента;

- отчет о логике назначения клиента.

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

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

Программное обеспечение (ПО) - комплекс программ системы обработки информации и программных документов, нужных для работы таких программ. ПО необходимо для придания ИС некоторых свойств, связанных с ростом производительности, достоверности получаемых результатов, надежности работы системы, оптимизации работы пользователя [18, c.35].

Критериями выбора ПО, присутствующего на ПК пользователей, является максимальное сокращение времени описания проблемы пользователей и отправки ее по e-mail. В разрезе корпоративного стандарта на предприятии ЗАО «Промет» применяется MS Outlook 2003. Для работы данной программы на ПК нужно установить ОС, которая поддерживает работу такого приложения. Ввиду корпоративного стандарта используется версия ОС MS Windows XP PRO, поскольку это самая ранняя версия ОС, поддерживаемая компанией Microsoft в нашей стране и способная функционировать в доменной инфраструктуре. Учитывая все вышесказанное, Win XP Pro sp3 Rus будет применяться в роли пользовательской ОС. Итог: на рабочих станциях пользователей нужно установить такие программные продукты, как:

- ОС Windows XP Pro sp3 Rus;

- почтовый клиент MS Outlook 2003.

Программа-служба (сервис) по обработке e-mail – это программа, созданная на скриптовом языке Python, постоянно анализирующая общий почтовый ящик ИТ-отдела и обрабатывающая входящие письма, формирующая и изменяющая заказы в БД, при этом распределяя их между свободными менеджерами, или ставящая их на поток [30, c.189]. Учитывая ограниченный бюджет и наличие опыта написания скриптов, у администратора ИС, был выбран скриптовый язык Python.

Критериями выбора архитектуры реализации проектируемого программного комплекса являются:

- совместимость с текущей инфраструктурой серверов;

- опция создания резервных копий сведения и просмотра статистика по обработанным заказам.

При определении ОС под это решение был определен MS Windows Server 2003, поскольку такой вид серверных ОС не очень требователен к ресурсам, а также давно применяется в инфраструктуре ЗАО «Промет».

Для серверной части нужно определить СУБД. В таблице 1.5 отображены ключевые современные СУБД.

СУБД для программы будет являться Oracle 11. Данный выбор сделан не просто так, главная ИС учёта заявок HP OpenView Service Desk строится как раз на этой БД.

Покупать новый сервер не нужно, поскольку БД программного продукта может находиться на уже существующем сервере «SD». При создании нового сервера фирмы заложила примерно половину мощности закупаемого сервера на дальнейшую масштабируемость ИС, но загруженность сервера увеличилась только на 15%, тогда как БД за 3 года непрерывно наращивалась [18, c.77].

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

Сравним ключевые методы и средства проектирования (таблица 1.6).

Таблица 1.6 - Основные средства проектирования

Написание программы сервиса, обрабатывающего e-mail, будет реализовано на языке Python. Этот выбор сделан неспроста. Прежде всего, администратор ИС «HP OpenView ServiceDesk» может писать программы на данном языке. Также, Python просто в освоении и среди новичков пользуется популярностью [8, c.11]. Стоимость проектирования ПО на данном языке намного меньше, чем на основе Borland C++ или Microsoft Visual C++. Вместе с тем, Python интенсивно прогрессирует, обладает открытой архитектурой и легко дает возможность создать графический интерфейс в форме HTML-странички (web-интерфейс).

2 глава. Проектная часть

2.1. Информационная модель и ее описание

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

В CRM-системе все клиенты подлежат учету. Каждая «зацепка» («лид») в системе, которая потом может привести к продаже, фиксируется. Таким «лидом» может быть «холодный» звонок от клиента, e-mail сообщение, посещение офиса и т.д. Ключевая задачи менеджера по продажам - определить, кто это и что нужно этому потенциальному клиенту. Когда данные о клиенте заполняются, «лид» превращается в контакт и фирму (если клиент представляет юридическое лицо), а далее в сделку (когда, вероятно, произойдет продажа).

Работа по такой схеме (от «лида» к контакту и к сделке) в CRM-системе «Битрикс 24» дает возможность максимально «дожать» все потенциальные зацепки и понять факт того, насколько эффективно работает отдел сбыта [19, c.43].

Рисунок 2.1 – «Лиды» в CRM-системе «Битрикс 24»

Внедрение такого типа системы в ЗАО «Промет» просто необходимо. Сотрудники ведут учет в бумажном виде, что может привести к потере клиентов. Да и руководителю будет понятнее, какой курс для фирмы выбирать дальше.

2.2. Характеристика нормативно-справочной, входной и оперативной информации

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

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

На разработку ИС фирмы в настоящее время оказывает воздействие не только уровень организации формы управления и средств ТО, но и современные подходы к самой идее проектирования [22, c.41].

Рисунок 2.2 – Декомпозиция проекта внедрения ИС

Создание проектной команды является ответственной стадией в ходе осуществления проекта. При создании проектной команды нужно принимать во внимание личностные и психологические качества участников проекта, а также руководствоваться критериями подбора участников проекта [11, c.234].

2.3. Характеристика результатной информации

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