Если изображать Цели и Задачи "ящиками деятельностей" IDEF0, мы не можем сделать так, чтобы Задача была вложена одновременно и в "ящик" Цель1 и в "ящик" Цель2.

Задача - блок функциональный, а цель - это управление, как такой подход?

Задача - блок функциональный, а цель - это управление, как такой подход?

Пожалуй, описанную мной проблему увязывания нескольких целей с одной задачей (функциональным блоком) , такой подход решает.
Но тогда получается, что управление в данном случае - это один из входов в систему. Если достижение цели должно являться результатом работы системы, то по идее цель должна как-то соотноситься с результатом работы системы, т.е. с её выходом. Может быть целевой показатель - это всё-таки выход, а не вход системы? Управление, как правило, не сводится просто к указанию цели, это скорее реакция на рассогласование имеющихся результатов с целевыми. Например, представляется достаточно странным указывать в качестве управления (цели) "достижение заданной доли рынка такого-то вида услуг" и даже "подготовка налоговой отчетности".
ИМХО в этом смысле IDEF0 вообще не приспособлен для указания целей и, возможно, не стоит грузить "старичка" задачами для которых он изначально не предназначался.
Возможно, удобнее для этих целей использовать диаграмму Use cases. Если подразумевать под UC некий набор задач, которые могут быть использованы в качестве средства для достижения цели, то увязав их с конкретными действующими лицами мы неявно увязываем их (UC и задачи) с целями эти лиц. И если проблемы проекта связаны именно с логикой увязки действующих лиц (и их целей) с задачами, то такая картинка может быть полезна для обсуждения с другими и   даже для собственного понимания .

Всем привет.
Цель и задача: качество и количество, внутреннее и внешнее, субъективное и объективное.
Но в разговоре про различие целей и задач есть еще один момент. По теории:

• система состоит из элементов;
• каждый элемент системы подчиняется общей цели;
• каждый элемент системы оказывает влияние на все другие элементы системы.

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

Если достижение цели должно являться результатом работы системы, то по идее цель должна как-то соотноситься с результатом работы системы, т.е. с её выходом. Может быть целевой показатель - это всё-таки выход, а не вход системы?

Абсолютно правы - бес попутал :-)
А вообще моделирование цели можно производить разными путями. Лучше вероятно для этого использовать не UC, а диаграммы классов со стереотипом "goal" (в розе мишень со стрелочкой). В результате можно попытаться реализовать структурную модель:
цель - качественная и количесвенная
цель - атрибуты (формул-ка цели, критерии достижения, факторы риска. ограничения и т.п.)
цель - операции (даже не знаю что придумать)
Далее можно сделать связь - цель - решается в ходе - задача - имеет - вариант решения - формализируется в виде - вариант использования - состоит из - ....

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

Фактически такое толкование допускает любая уже существующая IDEF0 диаграмма. Проблема если у нас одна подцель (задача) соответствует нескольким целям. В BPwin такое нарисовать можно только разместив все цели и подцели на одной диаграмме. Жалко, что в этом случае нет возможности "упаковать" подцель "внутрь" обоих целей, как это можно сделать для "обычной" иерархической структуры задач (с непересекающимися ветвями иерархии).

Всем привет.
Цель и задача: качество и количество, внутреннее и внешнее, субъективное и объективное.
Но в разговоре про различие целей и задач есть еще один момент. По теории:

• система состоит из элементов;
• каждый элемент системы подчиняется общей цели;
• каждый элемент системы оказывает влияние на все другие элементы системы.

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

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

1. Насчет того, что система порождает цели - такое утверждение ИМХО справдливо, если Вы полагаете под системой не только программно-технический комплекс (компьютер), но и людей которые используют его в соответствии со своими целями (цели порождают люди).  Очень часто под системой подразумевают всё-таки именно компьютер и при таком прочтении, конечно, утверждать возможность постановки цели самой системой несколько странно. Но такое терминологическое различие использования понятие "система" приходится иметь в виду. В том числе при обсуждениях в данном форуме .

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