Аис1
.pdfпередаваемых в процесс «Отгрузка и получение».
Алгоритм проведение реинжиниринга:
1. С целью реорганизации процесса производства компьютеров и их тестирования произвести расщепление модели:
1.1.средствами Windows создать копию модели «Деятельность компании» с именем «Предлагаемая модель компании»; 1.2.открыть модель «Предлагаемая модель компании»;
1.3.в диалоговом окне Model Properties изменить свойства:
·на вкладке General: в текстовой строке Name задать имя «Предлагаемая модель компании», и в зоне Time Frame установить переключатель TO-BE;
·на вкладке Purpose в одноименном текстовом окне указать цель модели
«Документировать предлагаемые изменения бизнес-процессов компании»; переименовать блок «Сборка и тестирование компьютеров» в «Производство продукта».
2. С помощью команды контекстного меню Split Model расщепить блок «Производство продукта» в модель с тем же названием. Задать требуемые свойства новой модели. Внести следующие изменения в созданную модель:
2.1.произвести декомпозицию функции «Сборка настольных компьютеров». Задать свойства новой диаграммы А2.1 «Сборка настольных компьютеров»; 2.2.переместить блок «Тестирование компьютеров» с диаграммы-источника АО "Произ-водство продукта» на диаграмму-цель А2.1 «Сборка настольных компьютеров». Для этого на вкладке Activity браузера на диаграмме-источнике выделить перемещаемый блок, щелкнуть по его пиктограмме и перетащить пиктограмму в диаграмму-цель этой же модели; 2.3.переименовать блок «Сборка настольных компьютеров» в «Сборку продукта»;
2.4.в связи с тем, что после реинжиниринга процесс сборки ноутбуков будет являться со-ставной частью функции «Сборка продукта» удалить блок «Сборка ноутбуков»; 2.5.переименовать стрелку «Заказы на настольные компьютеры» в «Заказы на
изготовление продукта». Задать свойства новой стрелки; 2.6.переименовать блок «Отслеживание расписания и управление сборкой и тестированием» в «Планирование производства»; 2.7.создать функцию «Разработать конфигурацию». Задать свойства новой функции;
2.8.от стрелки «Персонал производственного отдела» создать ветвь с именем «Систе-мотехник» и направить ее как стрелку механизма к блоку «Разработать конфигурацию»; 2.9.создать граничную стрелку от выхода блока «Разработать конфигурацию» с
именем «Стандарты на продукцию». Тоннелировать стрелку и задать ее свойства; 2.10.создать ветвь стрелки «Стандарты на продукцию» с именем «Список необходимых компонентов», идущую к управлению блока «Планирование производства»; 2.11.удалить стрелку управления «Правила сборки и тестирования». Вместо нее
создать ветвь стрелки «Стандарты на продукцию» с тем же именем «Правила сборки и тестирования», идущую к управлению блока «Сборка продукта»; 2.12.переименовать стрелку «Диспетчер» в «Планировщика производства»; 2.13.к блоку «Планирование производства» добавить;
2.13.1.граничную управляющую стрелку «Прогноз продаж». Тоннелировать стрелку; 2.13.2.граничную управляющую стрелку «Информация от поставщика». Тоннелировать стрелку; 2.13.3.граничную стрелку выхода «Заказ поставщику». Тоннелировать стрелку;
2.14.на диаграмме АО тоннелировать стрелку «Собранные компьютеры»; 2.15.появившуюся на диаграмме «Производства продукта» стрелку выхода связать с вы-ходом блока «Сборка продукта».
261
3. Для включения результатов реинжиниринга процесса «Производство продукта» в основную модель «Предлагаемая модель компании» необходимо произвести слияние моделей:
3.1.сделать модель «Предлагаемая модель компании» активной;
3.2.в контекстном меню блока «Производство продукта» выполнить команду Merge
Model;
3.3.в открывшемся диалоговом окне Merge Model установить флажки Cut/Paste entire dictionaries и Overwrite existing fields. Щелкнуть по кнопке ОК;
3.4.в слившейся модели на диаграмме АО тоннелировать стрелки «Информация от по-ставщика» и «Заказ поставщику»; 3.5.направить стрелку «Прогноз продаж» с выхода блока «Продажи и маркетинг» на управление блока «Производство продукта»;
3.6.направить стрелку «Стандарты на продукцию» с выхода блока «Производство продукта» на управление блока «Продажи и маркетинг»; 3.7.удалить ветвь стрелки управления «Правила и процедуры» блока «Производство про-дукта»;
3.8.для облегчения зрительного восприятия информации произвести реорганизацию размещения объектов на диаграмме; 3.9.закрыть модель «Производство продукта».
4. К обязанностям дизайнера относится разработка стандартов предприятия на продукцию, создание правил сборки и тестирования, определения перечня необходимых для закупки компонентов. Т.е. ролевой функцией дизайнера является управление производством продукта в целом, кроме того, управление процессом «Продажи и маркетинг». Поэтому блок «Разработать конфигурацию» на диаграмме АО должен быть на верхнем уровне:
4.1.с помощью браузера Model Explorer блок «Разработать конфигурацию» перенести с диаграммы «Производство продукта» на диаграмму АО;
4.2.реорганизовать диаграмму А0 «Деятельность компании»; 4.2.1.разрешить стрелку «Стандарты на продукцию»;
262
4.2.2.создать стрелку выхода «Маркетинговые материалы» от блока «Продажа и маркетинг»; 4.2.3.перенаправить стрелку «Стандарты на продукцию» - от выхода блока
«Разработать конфигурацию» на управление блока «Производство продукта»; 4.2.4.создать ветвь стрелки;
4.2.4.1.«Правила и процедуры» как управление блока «Разработать конфигурацию»;
4.2.4.2.«Стандарты на продукцию» как управление блока «Продажа и маркетинг»; при необходимости реорганизовать диаграмму А2 «Производство продукта».
5.Дальнейшее модифицирование модели TO-BE требует внесение новой информации
вдиа-грамму IDEF3 «Сборка продукта». Проведение реинжиниринга требует включение в функцию «Сборка продукта» процесса тестирования компьютеров, которое начинается после окончания процесса сборки компьютера и окончания процесса установки ПО. Если компьютер неисправен, в процессе тестирования у него заменяют компоненты, а информация о неисправных компонентах направляется в процесс «Подготовка компонентов». Т.о. результатом тестирования являются собранные компьютеры и неисправные компоненты. Для внесения новой информации в диаграмму IDEF3 «Сборка продукта»:
5.1.переместить блок «Тестирование компьютеров» на диаграмму IDEF3; 5.2.направить граничную стрелку от второго перекрестка к блоку «Тестирование компьюте-ров»; 5.3.провести две граничные стрелки «Собранные компьютеры» и «Неисправные
компоненты» от блока «Тестирование компьютеров».
6. Деятельность отдела продаж и маркетинга заключается в: ответах на телефонные звонки клиентов, предоставлении клиентам информации о ценах, оформлении заказов, внесении заказов в информационную систему и исследовании рынка. Поэтому на основе этой информации необходимо произвести декомпозицию функции «Продажи и маркетинг»:
6.1.по нотации IDEF0 создать три новых блока: «Предоставление информации о ценах», «Оформление заказов», «Исследование рынка»; 6.2.задать свойства новой диаграммы и требуемые свойства новых функций;
6.3.граничные стрелки «Стандарты на продукцию» и «Правила и процедуры»
263
являются управлением для всех трех функций; 6.4.граничная стрелка «Результаты сборки и тестирования является управлением для функции «Исследование рынка»;
6.5.граничная стрелка «Звонки клиентов» является входом для функций «Предоставление информации о ценах» и «Оформление заказов»; 6.6.механизмом для функции «Оформление заказов» является бухгалтерская система; 6.7.выходом для процесса «Оформление заказов» являются оформленные заказы клиентов;
6.8.выходом процесса «Исследование рынка» являются прогноз продаж и другие маркетин-говые материалы.
Создание диаграммы DFD
Оформление заказа проводится поэтапно:
на основании звонка клиента с желанием приобрести компьютерную технику существующая БД проверяется на наличие информации о клиенте;
если клиент обращается в фирму первый раз, то новая информация добавляется в БД;
если клиент обращается в фирму не первый раз, но информация о нем в БД устарела, то осуществляется ее обновление и редактирование;
оформляется заказ на компьютерную технику. В заказ включается информация о
клиенте и информация о заказанных продуктах.
Движение информации моделируется диаграммами DFD. При декомпозиции диаграммы IDEF0 согласно правилам DFD осуществляется преобразование граничных стрелок во внутренние, начинающиеся и заканчивающиеся на внешних ссылках.
Алгоритм создание DFD-диаграммы:
1. На диаграмме «Продажа и маркетинг» декомпозировать процесс «Оформление заказов».
2. .В открывшемся диалоговом окне Activity Box Count указать количество блоков декомпозиции 2 и установить переключатель нотации DFD .
3.Щелкнуть по кнопке ОК.
4.Задать свойство новой диаграммы.
5.Задать имена и свойства двух новых блоков: «Проверка и внесение клиента» и «Внесение заказа».
6.Добавить на диаграмму три хранилища данных: «Список клиентов», «Список продуктов» и «Список заказов».
7.Согласно требованиям нотации DFD необходимо удалить все граничные стрелки.
8.Внести в диаграмму внешнюю ссылку «Звонки клиентов».
9.Создать внутренние ссылки, имена для которых задавать с помощью словаря: 9.1.информация, содержащаяся в звонках клиентов должны являться входом для обоих блоков; 9.2.информация о клиенте поступает/извлекается из соответствующей БД – списка
клиентов. Тип стрелки отображающей движение информации – двусторонняя; 9.3.информация о клиентах необходимая для оформления заказа извлекается из списка клиентов; 9.4.информация о заказах поступает/извлекается из соответствующей БД – списка
264
заказов. Тип стрелки отображающей движение информации – двусторонняя.
10.На родительской диаграмме следует тоннелировать стрелки, подходящие и исходящие из блока «Оформление заказов».
Использование OFF-PAGE REFERENCE
на диаграмме DFD
Для отображения стрелок диаграмм декомпозиции одного уровня используется инструмент
Off-Page Reference.
Алгоритм создания межстраничных ссылок на диаграммах DFD:
1.Декомпозировать блок «Исследование рынка» на диаграмме А2 по нотации DFD на 3 новых функции с именами «Разработка прогнозов продаж», «Разработка маркетинговых материалов» и «Привлечение новых клиентов».
2.Присвоить новым функциям имена «Разработка прогнозов продаж», «Разработка маркетинговых материалов» и «Привлечение новых клиентов». Задать требуемые свойства диаграммы и блоков.
3.Удалить граничные стрелки.
4.Создать три хранилища данных «Список клиентов», «Список продуктов» и «Список заказов». Задать их свойства.
5.Создать на диаграмме две внешние ссылки «Маркетинговые материалы» и «Прогноз продаж». Задать их свойства.
6.Связать объекты диаграммы DFD стрелками:
6.1.сведения из БД «Список заказов» в виде заказов клиентов поступают для разработки прогноза продаж; 6.2.результаты разработки прогноза продаж могут отправляться в другие процессы;
6.3.сведения из БД «Список продуктов» в виде стандартов на продукцию поступают для разработки маркетинговых материалов; 6.4.результаты разработки могут маркетинговых материалов отправляться в другие процессы;
6.5.сведения из БД «Список клиентов» в виде информации о клиентах используются для привлечения новых клиентов.
7. На родительской диаграмме тоннелировать стрелки, входящие и исходящие из блока «Исследование рынка».
8. После внесения данных о новых клиентах в БД «Список клиентов» информация их процесса «Проверка и внесение клиента» на диаграмме «Оформление заказов» должна направляться в процесс «Привлечение новых клиентов» диаграммы «Исследование рынка». Для отображения движения информации используется
265
межстраничная ссылка Off-Page Reference:
8.1. на диаграмме «Оформление заказов» создать граничную стрелку выхода блока «Проверка и внесение клиента» с именем «Информация о новом клиенте»;
8.2.в контекстном меню наконечника стрелки выбрать команду Off-Page Reference; 8.3. в открывшемся диалоговом окне Off-Page Arrow Reference выбрать в качестве диаграммы «Исследование рынка»;
8.4.в контекстном меню диаграммы выбрать команду Model Properties,и на вкладке
Display в зоне Off-Page Reference label установить переключатель Node number; 8.5.на диаграмме «Исследование рынка» направить стрелку «Информация о новом клиенте» на вход блока «Привлечение новых клиентов».
Построение функциональной модели процесса финансовой деятельности договорного отдела
Вэтом разделе рассмотрим:
1.Декомпозиция процесса финансовой деятельности договорного отдела.
2.Дерево функций процесса финансовой деятельности договорного отдела.
3.Построение схемы реляционной базы данных .
Построение схемы реляционной базы данных
Схема базы данных состоит из 15 таблиц и связей между ними. Таблицы «Фирмы», «Банки», «ВТК», «Сотрудники», «Вид движения денежных средств по договору», «Вид документа», «Форма справки» являются независимыми таблицами и выполняют функции справочников. Таблица «Фирмы» содержит поля для хранения данных о фирмах, с которыми договорной отдел каким-либо образом связан. Таблица «Банки» содержит поля для хранения данных о банках. Так как разные фирмы могут иметь счета в одном и том же банке, то информация о банках была отделена от информации о фирме и выделена в отдельную таблицу. Таблица «Банки» связана с таблицей «Фирма» по полю «Код банка», связь типа
1:n.
Таблицы «ВТК» и «Сотрудники» содержат поля для хранения информации о ВТК и сотрудниках соответственно. В связи с тем, что один и тот же сотрудник может работать по договору подряда в нескольких ВТК, а один ВТК включает в себя несколько сотрудников, то для создания связи между этими таблицами была разработана промежуточная таблица «Членство в ВТК», которая связана с таблицами «ВТК» и «Сотрудники» как n:1. Введение этой таблицы позволило разрешить проблему с созданием связи типа m:n между
266
таблицами «ВТК» и «Сотрудники». В таблице «Сотрудники» может храниться информация и о сотрудниках договорного отдела .
Таблица «Вид движения денежных средств по договору» должна выполнять функции служебной таблицы и содержит информацию о видах движения денежных средств по договору. На момент прохождения преддипломной практики было выделено пять видов движения денежных средств по договору: приход по договору, оплата работ соисполнителя, оплата расходов на материалы, оплата командировочных расходов, выплата зарплаты ВТК. Таблица «Вид документа» предназначена для хранения информации о документах, используемых в финансовой деятельности отдела. В этой таблице должны храниться сведения о всех видах документов (входящих, исходящих, внутренних, справок для руководства, документов для других отделов).
Таблица «Форма справки» предполагает хранение сведений о возможных формах справок, запрашиваемых руководством организации.
Таблицы «Договоры» и «Этапы» являются одними из главных в структуре базы данных. Именно в этих таблицах будет храниться основная информация о работе договорного отдела. Таблица «Договоры» предполагает хранение сведений как о договорах с заказчиками, так и о договорах с соисполнителями. При этом в структуре таблицы предусмотрено поле «Код договора с заказчиком», по значению которого можно определить, является ли договор основным или нет. Таблица «Этапы» предназначена для хранения данных об этапах договора, эта таблица связана с таблицей «Договоры» по полю «Код договора» как n:1 (так как один договор может иметь несколько этапов, один этап принадлежит только одному договору). Таблица «Этапы» по аналогии с таблицей «Договоры» содержит поле «Код этапа договора с заказчиком», по значению которого также можно определить, к какому этапу основного договора относится данный этап.
Таблица «Документы к договору» предназначена для хранения информации о всех документах, относящихся к договорам. В этой таблице должны отражаться данные о документах, полученных из внешних источников, о документах, производимых в отделе для внешних источников, для других отделов. В таблице предусмотрены поля для хранения информации о дате создания, дате регистрации, о подписании документа, о сумме документа (для платежных поручений). Таблица «Документы к договору» связана с таблицей «Вид документа» по полю «Код вида документа» как n:1, с таблицей «Договор» по полю «Код договора» как n:1.
Таблица «План расходов по этапу» предназначена для хранения информации о плановых суммах расхода по статьям расхода этапа. В дальнейшем эти данные могут быть использованы для расчета структуры цены к этапу и к договору. Таблица «План расходов по этапу» связана с таблицей «Этапы» по полю «Код этапа» как n:1, с таблицей «Вид документа» по полю «Код вида документа» как n:1.
Таблица «Расходы и приходы» также является одной из самых главных для финансовой деятельности договорного отдела, так как предполагает хранение сведений о движении денежных средств по договору. Таблица «Расходы и приходы» связана с таблицей «Этапы» по полю «Код этапа» как n:1, с таблицей «Документы к договору» как n:1, с таблицей «Вид движения» по полю «Код вида движения» как n:1.
Таблица «Справка к договору» предназначена для хранения данных о всех справках, которые будут составлены по договору. Таблица связана с таблицами «Договоры» по полю «Код договора» как n:1, «Форма справки» по полю «Код формы справки» как n:1 и содержит поля для хранения информации о дате создания и признаке действительности справки.
267
Декомпозиция процесса финансовой деятельности договорного отдела
Осуществление финансовой деятельности должно обеспечивать выполнение основных функций финансов организации. С другой стороны, финансовая деятельность организации складывается из нескольких направлений: планирование, осуществление, анализ, регулирование. Таким образом, декомпозиция процесса финансовой деятельности велась с учетом выполнения основных функций финансов организации, а также с учетом всех направлений финансовой деятельности в отделе.
Схема декомпозиции, позволила определить множество функций для каждого блока нижнего уровня.
Кблоку «Планирование дохода» относятся работы, связанные с заключением договора с заказчиком и составлением пакета документов к нему. В частности, основным документом, от-ражающим плановые суммы дохода на срок действия договора, является календарный план, в котором указаны этапы работ, стоимость и сроки начала и окончания каждого этапа. Кроме того, к этому блоку относятся работы по созданию внутренних документов - таблиц в книге учета договоров «Сведения о договоре», «План работ по договору», которые впоследствии служат плановыми графиками поступлений денежных средств от заказчика.
Кблоку «Получение дохода» относятся работы, связанные с оформлением документов для получения денежных средств по договору. Обычно заказчик оплачивает работы после того, как они выполнены. В этом случае договорной отдел должен подготовить пакет документов, на основании которых заказчик будет оплачивать работы. В такой пакет документов входят отчетные материалы о выполнении работ, акт сдачиприемки работ по конкретному этапу календарного плана. Также к этому блоку относятся работы по заполнению таблиц книги учет договоров о платежных документах, представленных к оплате заказчику (таблицы «Приходы», «Оплата работ соисполнителя», «Оплата счетов», «Оплата командировочных расходов», «Вы-плата зарплаты ВТК»).
Кблоку «Регулирование расходов» относятся работы, связанные с выявлением неоплаченных платежных документов.
Аналогично распределяются работы по осуществлению расходов.
Кблоку «Планирование расходов» относятся работы, связанные с составлением главного документа, представляющего собой план расходов и доходов по договору - структуры цены, также к этому блоку относятся работы по составлению расшифровок сложных статей расхода. Этот блок определяет вид и наличие таблиц для конкретного договора в книге учета договоров.
268
Блок «Осуществление платежей» содержит в себе все работы, связанные с оформлением выплат по договору (зарплата ВТК, выделение денежных средств ВТК на покупку материалов, выделение денежных средств ВТК на командировочные расходы, оплата работ соисполнителя). Также в этот блок входят работы по заполнению таблиц книги учета договоров (таблицы «Приходы», «Оплата работ соисполнителя», «Оплата счетов», «Оплата командировочных расходов», «Выплата зарплаты ВТК»).
Блок «Регулирование расходов» включает в себя работы по выявлению неоплаченных документов и внесению неучтенных данных в книгу учета договоров.
Дерево функций процесса финансовой деятельности договорного отдела
В результате декомпозиции процесса была получена функциональная модель изучаемой предметной области. Число уровней декомпозиции составило 5, общее количество блоков выделенных функций (сложных и простых недекомпозируемых) составило 50, из них 33 – простые, не декомпозируемые.
269