ТЕМА 20. ЗАВЕРШЕНИЕ МОДЕЛИРОВАНИЯ

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

 

1. Размер SADT-моделей

Прежде чем обсуждать критерии для определения завершения процесса моделирования, посмотрим, как увеличивается размер sadt-модели. С точки зрения математики размер иерархических моделей типа SADT-моделей увеличиваются со скоростью геометрической прогрессии. В табл.20.1 показаны размеры полной четырехуровневой SADT-модели, каждая диаграмма которой состоит из четырех блоков, причем каждый из этих блоков декомпозируется аналогичной диаграммой.

В такой модели общее число блоков составляет 1365, а в четырехуровневой модели, содержащей по шесть блоков на диаграмме, общее число их - 9331.

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

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

Таблица 20.1

Размер иерархических моделей увеличивается

со скоростью геометрической прогрессии

Большие аналитические проекты обычно разбиваются на несколько отдельных более мелких проектов, каждый из которых создает модель одного конкретного аспекта всей проблемы. Поэтому вместо одной гигантской модели создаётся сеть из нескольких небольших моделей. Например, один аналитический проект, в котором принимали участие авторы этой книги, заключался в описании системы защитного оружия для подводной лодки. Вместо создания одной большой модели защищающей себя лодки были использованы отдельные модели для описания каждого вида оружия (например, торпеды), защитного средства (например, ловушки), средства доставки (например, пускового орудия) и консоли оператора. Таким образом, вместо огромной, неуправляемой модели, которую было бы трудно прочесть и понять, была создана серия небольших, управляемых и понятных моделей. Однако последние замечания не должны вас обмануть. Исключительно большие проекты могут привести к созданию высококачественной модели, состоящей из тысяч блоков. Но это случается редко. К счастью, большинство систем не требует для адекватного описания моделей такой величины.

2. Прекращение декомпозиции

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

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

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

3. Достаточная детализированность

В дальнейших рассуждениях будем использовать диаграмму рис. 20.1, поскольку эта диаграмма находится на самом "дне" модели экспериментального механического цеха.

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

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

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

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

Посмотрите на текущее расположение и высоту выбранного вами станка. Теперь опустите или поднимите его, чтобы вам было удобно работать. Затем измените его расположение, чтобы вы могли безопасно вставить, обработать и вынуть деталь. Может быть, для этого вам придется двигать, поворачивать или наклонять станок. Изучите устройство станка, прежде чем пытаться его налаживать.

Изменение уровня абстракции обычно происходит, когда модель уже имеет 2-3 уровня глубины, и их легко заметить. Небольшие изменения, однако, могут остаться незамеченными для автора. Обычно ошибки обнаруживаются в процессе рецензирования диаграмм. Свежий взгляд читательской аудитории определяет замену "что" на "как". Если изменение уровня абстракции не обнаружено во время цикла автор/читатель, то при следующей декомпозиции диаграммы оно обычно становится очевидным.

Рис. 20.1. Блоки, для которых нет необходимости в дальнейшей декомпозиции.

4. Изменение уровня абстракции

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

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

Посмотрите на текущее расположение и высоту выбранного вами станка. Теперь опустите или поднимите его, чтобы вам было удобно работать. Затем измените его расположение, чтобы вы могли безопасно вставить, обработать и вынуть деталь. Может быть, для этого вам придется двигать, поворачивать или наклонять станок. Изучите устройство станка, прежде чем пытаться его налаживать.

Изменение уровня абстракции обычно происходит, когда модель уже имеет 2-3 уровня глубины, и их легко заметить. Небольшие изменения, однако, могут остаться незамеченными для автора. Обычно ошибки обнаруживаются в процессе рецензирования диаграмм. Свежий взгляд читательской аудитории определяет замену "что" на "как". Если изменение уровня абстракции не обнаружено во время цикла автор/читатель, то при следующей декомпозиции диаграммы оно обычно становится очевидным.

5. Изменение точки зрения

Изменение точки зрения происходит примерно так же, как изменение уровня абстракции. Это чаще всего характерно для ситуаций, когда точку зрения модели нельзя использовать для декомпозиции конкретного блока, т.е. этот блок можно декомпозировать, только если посмотреть на него с другой позиции. Об этом может свидетельствовать заметное изменение терминологии

6. Сходные функции

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

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

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

Рис. 20.2. Сходные функции

7. Тривиальные функции

Тривиальная функция – это такая функция, понимание которой не требует никаких объяснений. В этом случае нам очевидна целесообразность отказа от декомпозиции, потому что роль SADT заключается в превращении сложного вопроса в понятный, а не в педантичной разработке очевидных деталей. Рассмотрим блок выбрать станок на рис. 20.1. Его свободно можно считать тривиальной функцией, потому что рабочие прекрасно знают, какой станок больше подходит для определенного рода обработки металла. Поэтому этот "тривиальный" блок не следует декомпозировать, чтобы не обидеть рабочих. Разумно избегать декомпозиции тривиальных блоков, особенно в организациях, имеющих доступ к государственным секретам. В таких случаях декомпозиция определенных блоков может принести больше вреда, чем пользы. Тривиальные функции лучше всего описываются небольшим объемом текста.

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

8. Принятие решения о завершении моделирования

Вероятность принятия неправильного решения о завершении моделирования может быть уменьшена, если вы оцените каждый блок, который хотите детализировать, в соответствии с приведенными выше правилами. Поскольку большинство SADT-моделей обычно содержат от 10 до 320 диаграмм, лучшее время для начала оценки блоков, когда модель достигает этих размеров. Если какая-то часть модели достигла уровня, не требующего дальнейшей декомпозиции, обращайтесь к своему собственному критерию для определения момента завершения моделирования, прежде чем декомпозировать блок, который еще не был детализирован.

Помните, что критерии, приведенные в этой главе, носят характер рекомендаций, следовательно, их нельзя применять механически. Иногда может случиться так, что в какой-то конкретной ситуации два правила будут противоречить друг Другу. Разрешение таких конфликтов требует рассудительности и осмотрительности. А это результат накопленного опыта. Если сложилась подобная ситуация и вы не знаете, что делать дальше, направьте на рецензирование специальную папку. Используйте цикл автор/читатель для привлечения наиболее опытных SADT-аналитиков, тех, кто с большей вероятностью даст вам дополнительную информацию для принятия обоснованного решения. Кроме того, советуют вести записи по сложным вопросам, по тому, как они были решены и что этому способствовало. Такие записи помогут вам впоследствии, если окажется, что моделирование следовало закончить раньше. Они помогут также при определении и выборе объектов будущего моделирования.

9. Резюме

SADT-модели иерархичны, и поэтому их размер может увеличиваться со скоростью геометрической прогрессии. Хотя многие SADT-модели имеют глубину 5-6 уровней, они чаще всего состоят не более чем из нескольких десятков диаграмм и редко превосходят предел в 100 диаграмм. Декомпозиция модели или ее части немедленно прекращается, если модель достигла уровня детализации, достаточного для достижения цели. Это происходит, когда модель достаточно подробна, чтобы ответить на все вопросы, которые включает цель модели, а также при изменении уровня абстракции или точки зрения. Кроме того, декомпозиция блока может быть прекращена, если окажется, что функции блока очень сходны с другой частью модели, которая уже декомпозирована. Таким образом, достаточность деталей, изменение уровня абстракции, изменение точки зрения и сходная функциональность являются основными критериями, которые применяют SADT-аналитики для определения момента прекращения декомпозиции.

ЧАСТЬ 3. ПРИМЕРЫ ПРОЕКТОВ И МОДЕЛЕЙ РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ

ТЕМА 21. ШАБЛОН ПРЕДСТАВЛЕНИЯ БИЗНЕСА-ПРОЦЕССА, ОТРАЖАЮЩИЙ КОНЦЕПЦИЮ ПРОЦЕССНОГО ПОДХОДА К УПРАВЛЕНИЮ ОРГАНИЗАЦИЕЙ В ПОНИМАНИИ ISO 9000:2000

1. Введение

Вашему вниманию предлагается шаблон бизнес-процесса, построенный в стандарте моделирования IDEF0 и отражающий концепцию процессного подхода к управлению организацией, заложенную в стандарты ISO 9000:2000.

Особенности построения стандарта ISO 9001:2000 позволяют применить его в любой сфере деятельности, при управлении любой организацией. Шаблон описания процесса содержится в разделах 5-:-8 этого стандарта. Если его прочитать внимательно, то можно выделить следующие основные моменты.

1. Система управления складывается, как минимум из 2-х уровней. Управленческие решения принимают  а) Генеральный директор «первое лицо» - раздел 5.6 ISO 9001:2000; б) «Хозяин процесса» - руководитель, отвечающий за эффективность процесса раздел 8.4 ISO 9001:2000.

2. Система управления основана на обязательных, регламентированных обратных связях описанных в цикле Деминга P-D-C-A ( Plan-Do-Check-Act) – Планирование – Работа- Проверка (Анализ) – Действие (Корректировка).

3. Все этапы цикла P-D-C-A выполняются по регламентам.

4. При проведении Анализа используются 4 основных потока информации:

а) показатели процесса;

б) показатели продукта;

в) показатели удовлетворенности потребителя;

г) результаты аудитов процессов.

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

6. Принцип цикла P-D-C-A тиражируется на нижние уровни управления (принятия решения) – если это целесообразно.

Предлагаемое вам описание абстрактного процесса и его декомпозиция на бизнес-процессы сделано в нотации IDEF0 с учетом основных требований процессного подхода к менеджменту организации, описанному в стандарте ISO 9001:2000. Данная схема является шаблоном для создания моделей бизнес-процессов, учитывающих цикл непрерывного повышения эффективности процессов и организации в целом. (Подробнее см. работы В.В.Репина, В.Г.Елиферова).

2. Контекстная диаграмма бизнес-процесса, учитывающего цикл PDCA

3. Диаграмма А0.

4. Диаграмма А2

5. Диаграмма А21

6. Диаграмма А212

ТЕМА 22. Бизнес-процесс закупки ТМЦ

1. Перечень функций бизнес-процесса «ЗАКУПКИ»

На данной странице представлено описание бизнес-процесса закупок товарно-материальных ценностей промышленного предприятия. Модель иллюстрирует возможность встраивания в  процесс закупок предприятия цикла PDCA (Plan-Do-Check-Act) непрерывного улучшения процесса.

Отдел планирования закупок (ОПЗ):

1. Планирование закупок

1.1. Формирование плана закупок.

1.1.1. Формирование плана движения ТМЦ на основании плана расхода ТМЦ для производства и утвержденных заявок подразделений.

1.1.2. Формирование графика поступления ТМЦ на склады.  1.1.3. Формирование плана расчетов с поставщиками (график платежей за ТМЦ и план по изменению ДЗ и КЗ).

1.2. Анализ расхода ТМЦ, склада и корректировка плана закупок.

1.2.1. Анализ расхода ТМЦ и остатков на складах (анализ «план/факт»).

1.2.2. Анализ наличия ТМЦ на складе.

1.2.3. Корректировка плана закупок (включая график поступления ТМЦ).

1.3. Анализ и подготовка методик управления запасами ТМЦ.

1.3.1. Разработка норм по оборачиваемости запасов и нормативов по запасам ТМЦ на складах.

1.3.2. Анализ и разработка модели управления запасами ТМЦ предприятия.

Отдел аттестации поставщиков (ОАП):

1.4. Формирование базы данных поставщиков ТМЦ (маркетинг рынка поставщиков и формирование базы данных).

1.4.1. Получение требований к ТМЦ от подразделений предприятия.

1.4.2. Определение квалификационных требований по поставщикам.

1.4.3. Анализ рынка поставщиков.

1.4.4. Проведение тендеров на право поставки ТМЦ предприятию.

1.4.5. Выбор поставщиков в соответствии с квалификационными требованиями.

1.4.6. Работа с перечнем аттестованных поставщиков.

Технический отдел (ТО УЗ):

1.5. Формирование базы данных номенклатуры ТМЦ.

1.5.1. Получение номенклатуры и требований к ТМЦ от подразделений предприятия.

1.5.2. Ведение базы данных по номенклатуре ТМЦ.

1.5.3. Ведение базы данных нормативных документов (ГОСТ, ОСТ, ТУ).

1.5.4. Консультации подразделений по выбору взаимозаменяемых ТМЦ.

Отдел заказов (ОЗ):

2. Формирование заказов

2.1. Заключение договоров и подготовка спецификаций.

2.1.1. Заключение долгосрочных договоров с аттестованными поставщиками.

2.1.2. Заключение разовых договоров с аттестованными поставщиками.

2.1.3. Разработка и согласование спецификаций договоров поставки ТМЦ.

2.2. Обеспечение договорной работы.

2.1.1. Юридический контроль договоров.

2.1.2. Анализ экономической эффективности договоров.

2.2. Выполнять мониторинг движения ТМЦ (склад поставщика – перевозчик – склад предприятия).

2.3. Выполнять претензионную работу по ТМЦ.

2.4. Контроль исполнения договоров.

2.5. Получение и акцепт платежных документов.

2.5.1. Получение и акцепт счетов.

2.5.2.Получение счетов-фактур.

2.6. Внесение данных по работе с поставщиками в базу данных.

Склад ТМЦ:

3. Получение, хранение и отпуск ТМЦ.

3.1. Принимать и оприходовать ТМЦ.

Лаборатория входного контроля (ЛВК):

3.2. Выполнять входной контроль качества ТМЦ.

3.2.1. Выполнять контроль качества получаемых ТМЦ.

3.2.2. Выдавать заключения по соответствию ТМЦ закупочным требованиям.

Склад ТМЦ:

3.3. Хранить ТМЦ на складе.

3.4. Выполнять отпуск ТМЦ в производство.

3.5. Вести учет ТМЦ и формировать отчетность.

3.6. Вносить данные по работе с поставщиками в базу данных.

Отдел заказов (ОЗ):

4. Оплачивать ТМЦ и контролировать ДЗ и КЗ

4.1. Формировать графика платежей за ТМЦ.

4.2. Управление оплатой ТМЦ.

Финансовый отдел:

4.3. Оплачивать ТМЦ.

Отдел заказов (ОЗ):

4.4. Контролировать ДЗ и КЗ по договорам поставки ТМЦ.

Бухгалтерия:

5. Бухгалтерский учет операций по закупке ТМЦ.

Владелец процесса закупок, Отдел качества процесса закупок:

7. Управление качеством процесса закупок.

7.1. Планирование показателей процесса закупок.

7.2. Анализ процесса закупок.

7.3. Разработка и осуществление корректирующих и предупреждающих мероприятий.

7.4. Проведение аудита процесса закупок.

7.4. Проведение аудита процесса закупок.

2. Контекстная диаграмма А0

3. Диаграмма А0

4. Диаграмма А2 процесса закупок

5. Диаграмма А21

6. Диаграмма А212

7. Диаграмма А22

8. Диаграмма А222

9. Диаграмма А23

ТЕМА 23. Разработка документа "А", модель в IDEF0-IDEF3

В данном разделена шести диаграммах приводится пример графической схемы процесса разработки некоторого документа "А". Цель примера - демонстрация использования методик IDEF0 и IDEF3  в рамках одной модели. Пример является учебным и ориентирован на сотрудников предприятий, осваивающих методики IDEF.

1. Общая схема

Диаграмма 1.

2. Бизнес-процесс подготовки документа

Диаграмма 2.

3. Собрать и проверить информацию

Диаграмма 3.

4. Обработать полученную информацию

Диаграмма 4.

5. Выполнить анализ проекта документа

Диаграмма 5.

6. Согласовать и утвердить документ

Диаграмма 6.

ТЕМА 24.Бизнес-процесс управления поставкой товара

На данной странице представлено описание основного бизнес-процесса торговой компании. Компания занимается обслуживанием клиентов, осуществляя закупку продукции у оптового поставщика и управляя ее доставкой мелким и средним клиентам. Модель иллюстрирует возможность встраивания в основной процесс компании цикла PDCA (Plan-Do-Check-Act) непрерывного улучшения процесса обслуживания клиентов.

1. Контекстная диаграмма бизнес-процесса

Контекстная диаграмма бизнес-процесса

2. Диаграмма А0

Диаграмма А0

3. Диаграмма А2

Диаграмма А2

4. Диаграмма А21

Диаграмма А21

5. Диаграмма А211

Диаграмма А211

6. Диаграмма А212

Диаграмма А212

7. Диаграмма А213

Диаграмма А213

8. Диаграмма А214

Диаграмма А214