Я так и не понял чем нам должно помочь описание ОА? Эти два человека должны договориться - зачем мы описываем ОА, чем нам поможет это описание в ТЗ? Если нам чем-то может помочь описание Организации, то ее описываем, если процесс, то его, если то и другое, то и описываем то и другое.

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

Согласен.
Конечно, цель не в терминах, а в написании конкретного ТЗ.

Только получается что в любом ТЗ мы каждый раз описываем некий конкретный реально существующий автоматизируемый объект.
Нельзя так ставить вопрос "чем нам должно помочь описание ОА".
Описание ОА - это необходимость, описание ОА есть в любом ТЗ.
Хотим мы этого или нет, осознаем мы это или нет.

Другое дело: нужно ли нам осознание того факта, что независимо от нашего желания, но мы в любом ТЗ всегда описываем объект автоматизации.
Я думаю, что это осознание нужно. И вот зачем.

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

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

По этой причине создаются стандарты, ГОСТ-ы.
Что такое ГОСТ? Это набор понятий, терминов, методик, разделяемых(!) всеми пользователями этого ГОСТ-а. Это основа коллективного труда.
Если бы не было ГОСТ-а, согласитесь, всем нам писать ТЗ было бы сложнее.
Пришлось бы каждый раз что-то заново придумывать.
И скорее всего каждый для себя разработал бы свой "стандарт ТЗ", с логикой, понятной только ему самому, что затруднило бы понимание его ТЗ другими членами коллектива.

К сожалению, в обсуждаемом ГОСТ-е, не все понятия определены четко и ясно.
В результате, у нас нет их общего понимания, нет той необходимой общей методической базы.

И данная дискуссия подтверждает это.
Я напомню почему мы заговорили об ОА.
Изначально вопрос был о назначении системы.
Что такое назначение автоматизируемой системы так никто четко не сформулировал.
Только Эдуард написал: "Назначение системы - это цель использования системы, ее основная функция.". Немного проясняет, но не очень убедительно.
По-моему, Юрий пытался объяснить свое понимание назначения АС через объект автоматизации.
Другие участники темы не согласились  с его пониманием объекта автоматизации.
Так и пошло-поехало...

Хорошо.

Несмотря на то, что у меня была другая гипотеза насчет определения объекта автоматизации, я готов принять Ваше определение, чтобы продолжить обсуждение.
Юрий, приведите примеры из ГОСТ-а, которые подтверждают ваше определение, чтобы увеличить количество аргументов в его пользу.
Хорошо бы еще кроме ГОСТ-а 34.ххх ориентироваться и на ГОСТ 19.ххх. Так как в них терминология очень совпадает.

Хотелось бы еще услышать мнение других участников насчет этого определения ОА.

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

Насчет подтверждения гипотезы в ГОСТ... хотел бы обратить внимание на один момент - если бы в ГОСТ было хоть как-то определено, что есть ОА и какие они могут быть - мы бы не дискутировали об этом. Кроме этого предлагаю исключить из рассмотрения ГОСТ 19, он не имеет отношения к АС, а описывает порядок создания программного изделия. Программное изделие конечно может являться частью АС, но я не очень понимаю как он может быть полезен для понимания того, что есть ОА.

Мы уже обсуждали выше, через определение АС, через отношение ОА и АС и т.п., какие еще аргументы предполагаются?

Давайте пойдем от обратного - что в ГОСТе опровергает гипотезу и определения ОА, которое написал я?

Давайте пойдем от обратного - что в ГОСТе опровергает гипотезу и определения ОА, которое написал я?

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

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

"

Юра, правильно я понимаю, что ты постулируешь это определение ОА? А почему нельзя рассматривать ОА как автоматизируемый процесс или совокупность процессов в контексте организации или ее части? Разве так не будет логичнее?

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

В любом случае объектом автоматизации являются все или часть функций системы или части системы

"

Юра, правильно я понимаю, что ты постулируешь это определение ОА? А почему нельзя рассматривать ОА как автоматизируемый процесс или совокупность процессов в контексте организации или ее части? Разве так не будет логичнее?

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

В любом случае объектом автоматизации являются все или часть функций системы или части системы

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

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