Давайте попробуем оттолкнуться от того, с чем мы согласны - от определения АС. Если посмотреть как соотносятся объект автоматизации и собственно сама АС - включает ли АС в себя объект автоматизации? Или объект автоматизации находиться вне АС?

Да, действительно.
А то мы ушли в сторону от основного вопроса: что такое назначение системы.

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

Да, действительно.
А то мы ушли в сторону от основного вопроса: что такое назначение системы.

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

Т.е. включает процесс, как объект автоматизации?

Т.е. включает процесс, как объект автоматизации?

Вы наверно хотите сказать, что система не может включать в себя процесс.
Правильно я понял?

Да, согласен. Процесс - это динамика. Процесс не может быть элементом системы.

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

Я считаю, что скорее объект автоматизации включает в себя АС, при этом сам видоизменяясь.

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

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

Как правило, при написании ТЗ, автоматизируемые процессы сразу описываются "как будет", основываясь на процессах "как есть", но не анализируя их. Так же редко учитывается переход с существующих на видоизмененные бизнес-процессы, что приводит к различным проблемам на этапе внедрения, не связанным напрямую с АС (например принтер, которые печатает штрих-коды, наклеиваемые на входящие документы, один на 2 обособленных здания и на 20 человек). В наших реалиях, стадию бизнес анализа часто пропускают, просто ставится задача - цель разработки системы, и разработчики, вместе с аналитиками сломя голову бегут ее решать. Понятно, что это само по себе проблема, и на бизнес анализ почти никто, по моему опыту, не выделяет ни средств ни времени... В общем, все печально =)

Имеем две несколько разные точки зрения. Это нормально. Как я понимаю, es3000 заключает, что процесс - фактичически некоторое эмержентное свойство АС (?). Tinner говорит о том, что объект автоматизации включает в себя АС, и если принять, что объект автоматизации = процесс, то именно процесс содержит в себе АС - в любом случае имеем "надсистему" над АС (ну или говорим в вырожденном случае, что процесс и есть АС :-), и эта "надсистема" никак не определена в ГОСТ, если я не ошибаюсь ...

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

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

Юр может я что-то пропустил, где формулировались положения этой гипотезы, или ты только сейчас ее сформулировал?
И что это значит организация в контексте выполнения? Ты формулируешь, что ОА является организацией выполнения функций?

Может ты как фасилитатор сформулируешь еще раз лаконично все версии и гипотезы?

...Как я понимаю, es3000 заключает, что процесс - фактичически некоторое эмержентное свойство АС (?). ...

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

Процесс до автоматизации (автоматизируемый процесс), и процесс после автоматизации (автоматизированный процесс) - это в абстракции один и тот же процесс, реализуемый по разному.
Первый осуществляется в "ручном" режиме, второй - с использованием средств автоматизации. А по сути процесс не изменился.

Можно ли считать автоматизированный процесс свойством АС?
Затрудняюсь ответить.
С первого взгляда, кажется, что можно.

Так мы уйдем в философию, причем очень глубоко.
Начнем разбираться что такое "свойство".
Я недавно как раз читал книгу: Цофнас А.Ю. Теория систем и теория познания. 1999. Все-таки осилил до конца
В ней говорится о том, что объект, свойство, отношение - это суть одно и то же. Все зависит от того, с какой точки зрения смотреть на обсуждаемое явление.

Я считаю, что скорее объект автоматизации включает в себя АС, при этом сам видоизменяясь.

Если под объектом автоматизации (ОА) понимать описываемый процесс документооборота, то: как ОА не может включать в себя АС, так и АС не может включать в себя ОА.

Так как между ОА и АС совершенно другие отношения.
Эти отношения не являются отношениями включения.
Это отношения, как вы пишите, "видоизменения", т.е. реализации (как сказано в определении АС)

Грубо: АС реализует ОА.
Более полно: в деятельности АС реализуется ОА.

Юр может я что-то пропустил, где формулировались положения этой гипотезы, или ты только сейчас ее сформулировал?
И что это значит организация в контексте выполнения? Ты формулируешь, что ОА является организацией выполнения функций?

Может ты как фасилитатор сформулируешь еще раз лаконично все версии и гипотезы?

Эд, можно считать, что эта гипотеза была сформулировано в моем сообщении от 02 Августа 2013, 17:58:27.

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

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

Хорошо.

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

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

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

Коллеги,

Дискуссия очень интересная и может длится вечность, но ИМХО мы забили главный вопрос - ЗАЧЕМ?
Зачем (для чего) мы описываем ОА? Вот от этого и нужно двигаться.
* Если мы описываем его для галочки, чтобы был по ГОСТ, то тут нужно договариваться с Заказчиком, что там должно быть. Даже высыпав кучу аргументов, что там д.б., а Заказчик скажет описывать там мою маму, то придется так и сделать...
* Если мы описываем для другой цели, то и нужно понимать эту цель!

Дискуссия очень интересная и может длится вечность, но ИМХО мы забили главный вопрос - ЗАЧЕМ?

Оговорка по Фрейду? Саня, тебе бы мочить и забивать:)

Зачем (для чего) мы описываем ОА? Вот от этого и нужно двигаться.
* Если мы описываем его для галочки, чтобы был по ГОСТ, то тут нужно договариваться с Заказчиком, что там должно быть. Даже высыпав кучу аргументов, что там д.б., а Заказчик скажет описывать там мою маму, то придется так и сделать...

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

* Если мы описываем для другой цели, то и нужно понимать эту цель!

Как сказал, генацвали.

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

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

Не скажу что это идеальное определение, но Автоматизация. Все указывает на процесс.

Когда же мы обращаемся к разделу ГОСТ "Характеристика ОА", то мы указываем здесь важные моменты, связанные и с компанией, но все равно описываем не ее саму, а ее деятельность. Мне так кажется.

... Если мы описываем его для галочки ...

Нет, не для галочки

... Зачем (для чего) мы описываем ОА? Вот от этого и нужно двигаться. ... 
... Если мы описываем для другой цели, то и нужно понимать эту цель!...

Я этот момент для себя понимаю так:

Наверное цель описания ОА - написать понятное другим людям задание на создание автоматизированной системы.

Ведь чтобы создать АС, нужно прежде всего самому понимать, что мы автоматизируем, и донести это понимание исполнителям.
Для этого и описывают ОА, а также область применения, а также назначение и цели создания системы, и много всего другого.

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

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

Эд, не увидел ответа на свой вопрос - ЗАЧЕМ?

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

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

Нет, не для галочки

Я этот момент для себя понимаю так:

Наверное цель описания ОА - написать понятное другим людям задание на создание автоматизированной системы.

Ведь чтобы создать АС, нужно прежде всего самому понимать, что мы автоматизируем, и донести это понимание исполнителям.
Для этого и описывают ОА, а также область применения, а также назначение и цели создания системы, и много всего другого.

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

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

1. Думаю что тут следует говорить  не столько о целях, а об ОПРЕДЕЛЕНИИ того чем может являться ОА (а не описания ОА). Именно в этом ключе строится дискуссия. Для чего нам нужно определять ОА (в каждом конкретном случае, т.е. конкретном проекте) - для того, чтобы как минимум понимать границы проекта.
2. Не уверен, что ТЗ (суть документация о требованиях и порядке реализации) будет сделано принципиально иначе, если будет определен ОА как процесс или как организация "в контексте"... т.к. в ТЗ содержатся в первую очередь требования к АС. Другой вопрос - как будут определены границы АС.