Файл: МУ Контрольная Архитектура ИС.pdf

Добавлен: 15.11.2018

Просмотров: 1952

Скачиваний: 7

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
background image

26 

 

Установка модема 

Инсталляция 

операционной 

системы 

Программное 

обеспечение 

Инсталляция 

дополнительного 

программного 

обеспечения 

J1 

J2 

J3 

J4 

 

 

 

 
 
 
 
 
 
 
 
 
 

 

Рис. 38. Создание сценария 

 

2.4 

Задание № 8. Создание диаграммы Swim Lane 

 

Диаграмма  Swim  Lane  («дорожки»)  представляет  собой  разновидность  диаграммы  IDEF3.  Swim  Lane 

позволяет явно описать роли в конкретном процессе. Эта диаграмма разделена на полосы («дорожки»), каждой 
из  которых  может  быть  поставлена  в  соответствие  роль  из  словаря  Role.  После  преобразования  IDEF3- 
диаграммы в Swim Lane следует просто распределить работы (UOW-элементы) между ролями (по дорожкам). 

Вызовите словарь групп ролей Role Group с помощью меню Dictionary/Role Group... и создайте группу с 
названием «Персонал сборочного цеха». 

Вызовите  словарь  ролей  Role  с  помощью  меню  Dictionary/Role...  и  опишите  роли,  связанные  с  группой 
«Персонал сборочного цеха»: 
1.  Контролер; 
2.  Сборщик; 
3.  Системный администратор; 
4.  Тестировщик. 

Для каждого объекта IDEF3-диаграммы «Сборка настольных компьютеров», вызвав контекстное меню 
Roles, укажите исполнителей из списка ролей. 

На основе IDEF3-диаграммы создайте диаграмму Swim Lane. 

Распределите UOW-элементы по ролям. 

 

Установка 

материнской 

платы и 

винчестера 

 

 

 

 

 

 

Компоненты 

 

 

 

Подготовка 

компонент 

 

 

 


background image

27 

 

РЕИНЖИНИРИНГ БИЗНЕС-ПРОЦЕССОВ 

 

3.1 

Общая схема разработки моделей 

Основная  цель  реинжиниринга  бизнес-процессов  в  терминах  IDEF0  заключается  в  построении  модели 

ТО-ВЕ («как будет»). Естественно предположить, что данная модель базируется на реальном положении дел (AS- 
IS).  
Однако  в  отличии  от  модели  AS-IS,  модель  ТО-ВЕ  носит  предписывающий  характер.  В  ней  должны  быть 
учтены  и  исправлены  все  недостатки,  выявленные  в  процессе  анализа  модели  AS-IS.  Очевидно,  что  процесс 
построения обеих моделей носит итерационный характер и подчиняется одинаковым правилам моделирования. 

В  общем  случае  процесс  моделирования  включает  сбор  информации  об  исследуемой  области, 

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

В  определенном  смысле  моделирование  объединяет  итеративный  процесс  создания  модели,  нотации, 

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

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

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

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

опроса. 

Для получения наиболее полной информации используются различные ее источники (например,   чтение 

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

На  рис.  39  изображен  процесс  моделирования,  описанный  с  помощью  IDEF0-диаграммы.  Диаграмма 

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

Создание  модели (блок 2 на  рис. 39)  -  это второй важный этап в процессе моделирования,  на  котором 

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

Моделирование  -  инженерная  дисциплина.  Это  означает,  что  модели  создаются,  исходя  из 

действительной ситуации, и что эти модели проходят через серию последовательных улучшений до тех пор, пока 
они в точности не будут представлять реальный мир. Одним из основных компонент при этом является итератив- 
ное  рецензирование,  в  процессе  которого  автор  и  эксперт  многократно  совещаются  (устно  и  письменно) 
относительно  достоверности  создаваемой  модели.  Итеративное  рецензирование  называется  циклом  «автор- 
читатель». 

Цикл  «автор-читатель»  начинается  в  тот  момент,  когда  автор  принимает  решение  распространить 

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

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


background image

28 

 

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

Как  правило,  модель  редко  создается  одним  автором.  На  практике  над  различными  частями  модели 

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

Организация  своевременной  обратной  связи  имеет  важнейшее  значение  для  эффективного 

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

Модели  создаются  с  конкретной  целью,  и  эта  цель  записана  на  диаграмме  А-0  модели.  В  каком-то  

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

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

что  создаваемая  в  процессе  анализа  модель  будет  точна  и  используема  в  дальнейшем.  Эта  группа,  называемая 
условно  комиссией  технического  контроля  (блок  5  на  рис.  39),  отвечает  за  контроль  качества  моделей, 
создаваемых авторами проекта. Комиссия следит за выполняемой работой и ее соответствием конечным целям 
всего проекта. Специалисты комиссии обсуждают модель и оценивают, насколько она может быть использована 
и  будет  использована  соответствующим  образом  в  ходе  выполнения  проекта  для  достижения  его  глобальных 
целей. 

Таким  образом,  комиссия  технического  контроля  находится  в  наиболее  выгодном  положении  при 

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

 

 

3.2 

Задание № 9. Функционально-стоимостной анализ (Activity 
Based Costing) 

 

Функционально-стоимостной  анализ  (ФСА)  —  метод  определения  стоимости  и  других  характеристик 

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

Метод  ФСА    разработан    как    «операционно-ориентированная»  альтернатива    традиционным 

финансовым подходам. В частности, в отличие от традиционных финансовых подходов метод ФСА: 

  предоставляет информацию в форме, понятной для персонала предприятия, непосредственно участвующего  

в бизнес-процессе; 

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

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

В  основе  применения  метода  ФСА  лежит  разработка  и  применение  на  практике  ФСА-моделей.  Цель 

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

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


background image

29 

 

  формирование релевантной информации об эффективности деятельности центров ответственности на 

предприятии; 

  определение и проведение общего анализа себестоимости бизнес-процессов на предприятии 

(маркетинг, производство продукции и оказание услуг, сбыт, менеджмент качества, техническое и 
гарантийное обслуживание и др.); 

  проведение сравнительного анализа и обоснование выбора рационального варианта технологии 

реализации бизнес-процессов; 

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

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

  анализ интегрированного улучшения результатов деятельности предприятия и др. 

Построение функционально-стоимостных моделей осуществляется на основе применения 

методологической и технологической взаимосвязи между IDEF0- и ФСА-моделями. 

Связанность методов IDEF0 и ФСА заключается в том, что оба метода рассматривают финансово- 

хозяйственную деятельность предприятия как множество последовательно выполняемых функций, а дуги 
входов, выходов, управления и механизмов функций IDEF0-модели соответствуют стоимостным объектам и 
ресурсам ФСА-модели. 

На уровне функционального блока связь IDEF0 и ФСА-моделей базируется на трех принципах: 

1.  Функция характеризуется числом, которое представляет собой стоимость или время выполнения этой 

функции. 

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

(времен) всех подфункций на данном уровне декомпозиции. 

Следует отметить, что в AllFusion Process Modeler реализован упрощенный вариант ФСА. В то же время в 

программном  продукте  EasyABC  ФСА  реализован  полностью,  но  в  явном  виде  программная  поддержка 
взаимосвязи между IDEF0-моделью и EasyABC поддерживается только путем экспорта диаграммы Node Tree. 

Исходные данные для ФСА 

На производственном участке работают 5 сборщиков и 1 тестировщик. 
В среднем в день собирается 12 настольных компьютеров и 20 ноутбуков. 
Двое сборщиков - стажеры. 
Зарплата диспетчера - 500$ в месяц, сборщиков и тестировщиков -10$ в час, стажеров - 3$ в час. 
Средняя стоимость компонент для настольного компьютера -800$, для ноутбука -1400$. 

1.  В диалоге Model Properties (вызывается из меню Model) в закладке АВС Units установите единицы 

измерения денег и времени. 

2.  Перейдите в Model/Cost Center Editor... и в диалоге Cost Center Editor внесите название и определение 

центров затрат (табл. 7). 

 

Таблица 7 Описание центров затрат 

Центр затрат 

Определение 

Управление 

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

Рабочая сила 

Затраты на оплату рабочих, занятых сборкой и тестированием компьютеров 

Компоненты 

Затраты на закупку компонент 

 

3.  Для внесения центра затрат наберите наименование, определение и щелкните по кнопке Add. 

Стоимость каждой работы отображается в нижнем левом углу прямоугольника. 
Для  отображения  частоты  или  продолжительности  работы  перейдите  в  диалог  Model  Properties  (закладка 

Display),  и  переключите  радиокнопки  в  группе  АВС  Units.  Можно  вообще  отключить  режим  отображения 
информации об АВС, отключив опцию Activity Cost/Freq/Dur. в диалоге Model Properties или меню View. 

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

контекстном меню Cost Editor. 

5.  По табл. 8 внесите параметры АВС. 

Таблица 8 Исходные данные для ФСА 

Activity Name 

Cost Center 

Cost (SUS) 

Duration (Days) 

Frequency 

 


background image

30 

 

Отслеживание 
расписания и 
управление сборкой 
и тестированием 

Управление 

25,00 

1,00 

1,00 

Сборка настольных 
компьютеров 

Рабочая сила 

5,00 

1,00 

12,00 

 

Компоненты 

800,00 

 

 

Сборка ноутбуков 

Рабочая сила 

7,50 

1,0 

20,00 

 

Компоненты 

1400,00 

 

 

Тестирование 
компьютеров 

Рабочая сила 

2,00 

1,00 

32,00 

 

6.  Посмотрите результат - стоимость работы верхнего уровня. 
7.  Сгенерируйте отчет Activity Cost Report. 

 

3.3 

Задание № 10. Использование свойств, определяемых 
пользователем (User Defined Properties) 

 

1.  Перейдите в Model/UDP Definition Editor...» в диалоге User-Defined Property Dictionary Editor внесите 

название категорий. 

2.  Для внесения категории необходимо в поле New Keyword внести наименование категории и щелкнуть по 

кнопке Add Keyword. 

3.  Внесите следующие категории: 

Resources Consumption (расход ресурсов); 
Documentation (документация); 
Information System (информационная система); 
Quality Measure (мера измерения качества). 

4.  Создайте UDP. Для этого в поле "User-Defined Property (UDP) to be added after selected property" внесите 

имя UDP, например, «Quality». Затем выберите тип UDP из выпадающего списка Datatype - «Text List (Single 
selection)». Затем щелкните по кнопке Add. 

5.  Для UDP типа List необходимо задать список значений. В поле New Category/Member внесите значение «A- 

Terrific» и щелкните по кнопке Add Member. Затем внесите другие значения UDP Quality: 

B-Good 
С-ОК 
D-Poor 
E-Awful. 

6.  Для включения UDP в категорию щелкните по UDP в списке, затем щелкните по категории в нижнем списке, 

затем щелкните по кнопке Update. По табл. 9 внесите UDP. 

 

Таблица 9 Определение UDP 

Наименование 
UDP 

Тип 

Члены 

Категория 

Application 
(приложения) 

Text  List 
(Multiple 
Selection) 

COS- Customer Order System (модуль оформления 
заказов) ESS- Employee Sheduler System (модуль 
создания и контроля расписания выполнения 
работ) PIS- Parts and Inventory System (модуль 
учета комплектующих и оборудования) PTS- 
Procedures and Troubleshooting System (модуль 
процедур сборки и поиска неисправностей) 

Information System 

Screen 

Command 

 

Information System 

Additional 
Documentation 
(дополнительная 
документация) 

Command 
List 

Winword.EXE samplel.doc 
Winword.EXE sample2.doc 
POWERPNT.EXE sample3.ppt 

Documentation