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


Все сложно

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


Перед тем как делать любой ИТ проект неплохо было бы договориться в команде и со всеми заинтересованными лицами вне проекта, какого класса продукт мы поставляем:

  • Автоматизированная система;
  • Информационная система;
  • Программная система/комплекс;
  • Программно-аппаратный/программно-технический комплекс/система;
  • Программный продукт;
  • Программное изделие;
  • Программное средство.

А ведь существуют еще:

  • Сервис (автоматизированный);
  • Информационный продукт;
  • И еще как минимум 11 видов обеспечения:
    1. Программное;
    2. Информационное;
    3. Техническое;
    4. Лингвистическое;
    5. Математическое;
    6. Метрологическое;
    7. Эргономическое;
    8. Методическое;
    9. Организационное;
    10. Правовое;
    11. Инженерное.

И, наконец, если порыться в западных стандартах, добавятся:

  • Компьютерная система;
  • Система обработки информации;
  • И снова Информационная система, но уже в другом определении.

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

Немного определений

Однако, давайте посмотрим на определения и увидим, как плавают границы понятий.
Источниками определений служат ГОСТ 34, ГОСТ 19, официальные переводы ИСО/МЭК, неофициальные переводы ИСО/МЭК, по крайней мере один ФЗ РФ и словари.


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


Информационная система (ИС) – это (согласно ФЗ № 149-ФЗ от 27 июля 2006 г., Ст 2., п.3.) совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий (трактуемых, как "процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов", там же п.2.) и технических средств. С точки зрения логики это определение логически не корректное, но что есть – то есть.

Тут, правда, есть тонкость: понятие "информационная система" определяют по крайней мере еще два стандарта (ISO/IEC 2382-1 и ГОСТ РВ 51987) и каждый делает это чуть по своему, что несколько размывает границы понятия в реальной практике.
Ну и, конечно, википедия не добавляет четкости, предлагая еще пару толкований.
Если вчитаться в определения, например можно увидеть, что АС (ГОСТ 34)!=ИС (ФЗ), но практически АС (ГОСТ 34)==ИС (ISO/IEC 2382-1)
Вот и представьте себе совещание команды на старте проекта, где у каждого в контексте свое определение. Обычно оно плавно перерастает в ожесточенный спор. Кто-то начинает говорить о бизнес-процессах, их показателях, оргструктуре и методических решениях. Кто-то другой думает, что надо просто собрать требования с пользователей и написать, что они сказали, приемо-сдав на тестовом сервере. Кто-то считает, что в зоне ответственности команды будет интеграция, миграция и закупка "боевого" железа, а других это приводит в ужас. Не говоря уже о том, что ключевых заказчиков о рамках того, что они ждут на выходе, скорее всего и не спрашивали. Чего там, ИТ – они и в Африке ИТ.
В зависимости от выбранного определения системы и тонкой подстройки рамок бюджет проекта и длительность могут увеличиваться или уменьшаться на порядок.

Программное средство – стандартами не определяется, но есть словарь: Термин П. с. ЭВМ используется для обозначения любой программы, или последовательности логических команд, к-рая предписывает аппаратным средствам выполнить последовательность действий, необходимых для решения определенной задачи.


Программное изделие АС – (согласно ГОСТ 34.003) программное средство, изготовленное, прошедшее испытания установленного вида и поставляемое как продукция производственно-технического назначения для применения в АС;


Программное обеспечение АС – (согласно ГОСТ 34.003) совокупность программ на носителях данных и программных документов, предназначенная для отладки, функционирования и проверки работоспособности АС.


(Программный) компонент – (согласно ГОСТ 19.101) программа, рассматриваемая как единое целое, выполняющая законченную функцию и применяемая самостоятельно или в составе комплекса.


Программная комплекс – (согласно ГОСТ 19.101) программа, состоящая из двух или более компонентов и (или) комплексов, выполняющих взаимосвязанные функции, и применяемая самостоятельно или в составе другого комплекса.


Программный продукт – (согласно ГОСТ Р ИСО/МЭК 12207-99) набор машинных программ, процедур и, возможно, связанных с ними документации и данных;


Программно-аппаратный/программно-технический комплекс (такого термина официально тоже нет), но есть Комплекс средств автоматизации АС – (по ГОСТ 34.003) совокупность всех компонентов АС, за исключением людей.


Все виды обеспечения являются компонентами АС наряду с персоналом и определены (кроме инженерного) в ГОСТ 34.003.


Информационный продукт не имеет определения в ГОСТ, но есть словарь: "документированная информация, подготовленная в соответствии с потребностями пользователей и представленная в форме товара".


Зато в ГОСТ 34.003 есть следующее:

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

Драма со всем программным и информационным кроется в разном понимании итогового качества (а значит, и в разном составе работ и бюджете проекта):

  • программное средство – любая программа (включая скрипт админа, запускающий по расписанию бэкап БД);
  • программное изделие – отторгаемое от автора и места разработки/испытаний средство, снабженное документацией и прошедшее испытания;

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


Драма с использованием слов система и комплекс кроется в разнице между:

  • автоматизированная система – железо+софт+люди;
  • информационная система – информация+железо+процессы (вероятно, софт здесь считается информацией);
  • программно-техническая система/комплекс – железо и софт;
  • программная система/комплекс – только софт.

И опять здесь большие отличия в составе работ и бюджете проекта.


И есть еще калька Сервис, которое в Документ PDFглоссарии ITIL переведено, как Услуга. И определено, как "Способ предоставления ценности заказчикам через содействие им в получении конечных результатов, которых Заказчики хотят достичь без владения специфическими затратами и рисками. Термин «услуга» может использоваться для обозначения основной услуги, ИТ-услуги или пакета услуг."


В итоге, на сегодняшний день, лучше не опираться на "страшные слова" и всегда уточнять состав, рамки и точные свойства "той штуки, о которой мы все сейчас с вами говорим".

Картина в целом

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


Картинка же на самом деле достаточно проста. Вот она:



Однако, подкрутив приближение, это выглядит уже вот так:



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


Как получается, что проектные команды вместе с заказчиками до последнего момента путают, что же мы строим на самом деле. Есть разные варианты:

  • Бывает просто отсутствие опыта и образования. Все программисты проходят стадию "у меня работает, значит задача выполнена";
  • Продавцам коробочного ПО выгодно смешивать понятия, так как гораздо проще получить деньги за лицензии (которые есть воздух), чем влазить в рискованный и низкорентабельный проект внедрения;
  • Некоторым представителям заказчика это тоже выгодно: во-первых им менее рисковано покупать софт и не ввязываться во внедрение (пусть купленное ПО утилизирует кто-то другой), а во-вторых никто не отменял личный интерес некоторых менеджеров в быстрой продаже на солидную сумму.
  • Некоторые представители заказчика, далекие от ИТ, верят в то, что им говорят подавцы ПО. А обычно они обещают счастье сразу после покупки лицензий, умалчивая о самом факте существования понятия "полная соимость владения".
    Между прочим, инициация крупных внедрений может длиться годы из-за того, что продавцы заходят вперед конкретной маркой ПО, минуя как минимум две стадии построения АС. Пользователи разделяются на лагеря: одни верят и надеются, другие не видят связи между презентациями и демонстрпациями и своей работой, третьи видят связь, но так же видят множетство несоответствий между этой демонстацией и тем, что им надо в своей работе, четвертые троллят вопросом "что мы сэкономим/заработаем с помощью этого софта", пятые на самом деле сторонники другой марки ПО, но маскируются под предыдущих, шестые – местные автоматизаторы, которые уже построили, пусть и неказистую, зато работающую систему, они борются за свою систему и свои рабочие места, и много других вариантов. В итоге такого противостояния, как сказал один директор: "мы каждый месяц собираемся и смотрим маркетинговую презентацию на протяжении двух лет, но пока так ничего и не внедрили".
  • Менеджеры проектов, выросшие из ИТ, часто повторяют болезнь начинающих программистов "у меня все работает" на другом уровне – им кажется, что если не брать в рамки проекта лишние, непонятные и рискованные работы (а это, как минимум, все работы, в которых приходится сталкиваться с организационно-методическими реешниями, а так же массами пользователей и обеспечением качественной работы боевой системы), то все обойдется. Что бывает после этого я расскажу в следующем разделе.
  • Наверное, еще что-то бывает. Если у вас есть интересные истории, напишите мне :)

Как прострелить себе ногу, уменьшая рамки ИТ проекта

Еще одна разница, которая заключается в границах ответственности систем и их взаимосвязи.
Главный фокус в картинке ниже:



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

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

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

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

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