Объект автоматизации из воздуха

В очередной раз столкнувшись с критикой ГОСТ 34-ой серии, описывающей требования к проектированию автоматизированных систем, вспомнил об одной интересной коллизии, с которой сталкивался постоянно по ходу применения ГОСТ 34.602-89 (стандарт на ТЗ, если кто забыл). Это характеристика объекта автоматизации.
Кажется, уже все давно решили - и решили небезосновательно, -  что объектом автоматизации АС является деятельность (читай, процессы). Справедливости ради замечу, что в самом ГОСТ я конкретного указания на это не нашел - ГОСТ определяет содержимое раздела "Характеристики объекта автоматизации" следующим образом:
"2.5. В разделе «Характеристики объекта автоматизации» приводят:

• 1) краткие сведения об объекте автоматизации или ссылки на документы, содержащие такую информацию;
• 2) сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды.".

Но и каких-либо противоречий с формальной логикой тут нет - автоматизация необходима в первую очередь для деятельности (бизнес-процессов), а не для организаций, филиалов и подразделений.
Однако, если с тем фактом, что под объектом автоматизации понимаются процессы заказчика, большинство согласно, то с тем, откуда появляются эти процессы, возникают проблемы. Согласно, например, COBIT, бизнес-процессы определяют цели и требования к ИТ-процессам, которые в свою очередь определяют цели для ИТ-систем. И хорошо, если разработка АС осуществляется в рамках комплексных мероприятий по ИТ-консалтингу, где этапу технического проектирования предшествовали бизнес- и концептуальное проектирование системы, с анализом бизнес-процессов, "дорожной картой" развития систем автоматизации этих бизнес-процессов и даже какими-нибудь концептуальными моделями архитектуры разного уровня и степени детализации. В этом случае наличие бизнес-процесса идентифицируется и подтверждается отсылкой к диаграммам в какой-нибудь Business Studio с резолюцией "учи матчасть". Но что делать, когда разработка АС - это независимое (как сейчас модно говорить, суверенное) мероприятие, направленное на достижение различных целей, в диапазоне от "нужно внедрить это самое.." и "начальство постановило" до "у нас тут есть одна идея" и "глядите, какую классную штуку видел у конкурентов"?
Многие менеджеры или аналитики с техническим бэкграундом (к коим в какой-то мере отношусь и я) могут сказать, что соответствующая автоматизируемая деятельность появляется только с применением АС - а значит бизнес-процесс в исходном состоянии отсутствовал. В какой-то степени это может быть правдой, например, в случаях, когда АС создается, например, в целях исполнения федерального законодательства (например, взаимодействие с СМЭВ). Однако такая ситуация со стороны сильно напоминает анекдот про то, что совместная жизнь позволяет людям решать вместе множество проблем, которые бы не возникли, если бы они жили по отдельности.
В реальности ИТ-система не может и не должна создавать бизнес-процесс, так как создание системы не может выполняться ради самого создания системы. И даже если деятельность, автоматизируемая создаваемой системой, фактически появляется одновременно с АС, на мой взгляд крайне нежелательно об этом сообщать.
В этом случае я рекомендую опираться на зрелость автоматизируемого процесса. В том же COBIT описана крайне адекватная модель зрелости процессов, которая, в отличие от оригинальной модели CMMI, на мой взгляд, может быть применена к любым процессам. Согласно этой модели, первые три уровня зрелости определяются как:

• 0. Не существует. Полное отсутствие каких-либо процессов управления ИТ. Организация не признает существования проблем в ИТ, которые нужно решать, и, таким образом, нет никаких сведений о проблемах.
• 1. Начало (Анархия). Организация признает существование проблем управления ИТ и необходимость их решения. При этом не существует никаких стандартизованных решений. Существуют случайные одномоментные решения, принимаемые кем-то персонально или от случая к случаю. Подход руководства к решению ИТ-проблем хаотичен, признание существования проблем случайно и непоследовательно.
• 2. Повторение (Фольклор). Существует всеобщее осознание проблем управления ИТ. Показатели деятельности и ИТ-процессов находятся в развитии, охватывая процессы планирования, функционирования и мониторинга ИТ. Деятельность по управлению информационными технологиями описана и интегрирована в процесс управления организацией. Выбраны для улучшения и/или контроля те ИТ-процессы, которые влияют на основные бизнес-процессы предприятия. Эффективно выполняется планирование и управление инвестициями. Руководство организации регламентировало меры по управлению ИТ, а также методы управления и оценки, но процесс не был принят в организации. Не существует формализованного обучения, набора взаимосвязанных стандартных процедур управления, ответственность возложена на сотрудников. Сотрудники контролируют процессы управления с помощью проектов и ИТ-процессов. Ограниченные инструменты управления выбираются и внедряются для сбора метрик управления, но не используются в полном объеме из-за недостатков в оценке их функциональности. 

Логично предположить, что если возникла необходимость автоматизации какой-либо деятельности, значит эта деятельность так или иначе выполняется, пусть и крайне плохо, нерегулярно и наверняка незаметно для ее участников. Поэтому уровень зрелости "0.Не существует" следует исключить. Остальное на ваш выбор. В зависимости от степени реализации автоматизируемой деятельности у Заказчика, раздел "Характеристики объекта автоматизации" ТЗ по ГОСТ 34.602-89 можно наполнить переработанным описанием соответствующего уровня зрелости процесса, таким образом дав понять, что разрабатываемая система не только автоматизирует бизнес-процесс, но и повысит его зрелость (иногда - довольно существенно, так как даже самые типовые автоматизированные системы того или иного класса содержат довольно большое количество контролей автоматизируемых процессов).
В общем, я, как всегда, за вдумчивый и обоснованный подход к разработке любых проектных историй для бизнеса, так как это позволяет не только аргументировать и обосновать те или иные проектные решения, но и связать воедино и затем отследить все потребности и выгоды бизнеса в реализуемых ИТ-решениях.