Эффективность систем в их жизненном цикле через призму стандартов

Вопрос оправданности затрат на системы — автоматизированные системы (АС) и, в частности, информационные системы (ИС) — особенно серьезно стоит в периоды острого дефицита финансовых ресурсов. Бюджеты на ИТ в большинстве организаций сокращаются, в этих условиях необходимы обоснованные ответы на вопросы: насколько эффективны уже эксплуатируемые системы, можно ли от каких‑то отказаться, а также оправданно ли начинать создание или внедрение той или иной системы?

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

• в каких точках жизненного цикла систем и каким образом закладывается ясная и практически полезная оценка эффективности?
• какова роль стандартов для достижения этой цели — обеспечения управляемости в деле определения и использования оценок эффективности?
• как с этой целью можно применять стандарты на практике сегодня?

Общая платформа

Стандарты в этом деле нужны хотя бы по той причине, что эффективность ПО и ИС должна одинаково пониматься многими заинтересованными сторонами — в первую очередь заказчиками, поставщиками и пользователями систем. Необходима общая платформа, на которой эти заинтересованные лица могут действовать совместно, получая и используя эффективную систему. Более детально это означает, что заказчику и пользователям надо договориться о следующем:

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

Кроме того, заказчику и поставщикам необходимо договориться об одинаковом понимании ряда моментов:

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

Это понимание надо закреплять в контрактах на создание системы и в согласованных процедурах её испытаний и оценки проекта. Понятно, что такая работа должна проводиться на всем протяжении жизненного цикла (ЖЦ) системы — от замысла до ввода в эксплуатацию, во время эксплуатации и вплоть до отказа от системы и вывода ее из работы.

Одинаковое понимание эффективности

Существует значительный разброс в трактовках понятия «эффективность» применительно к ИТ и ИС. Известнейшие, в том числе основополагающие стандарты и методики своими определениями показывают весьма широкий их диапазон. В статье [1] на основе анализа различных трактовок и определений, содержащихся в стандартах, была показана необходимость основываться в первую очередь на широкой трактовке эффективности как комплексной характеристики системы:

«Эффективность — комплексная характеристика системы, отражающая степень ее соответствия потребностям и интересам ее заказчиков, пользователей, других заинтересованных лиц».

Поскольку основные потребности и интересы сторон в формализованном и агрегированном виде могут быть представлены как цели создания системы, эффективность с определенной точностью можно представлять как степень соответствия системы целям ее создания. К потребностям и интересам заинтересованных лиц можно отнести и соблюдение ограничений, например, на финансовые затраты, на время создания системы или на ее производительность. Определяемая таким образом эффективность позволяет учитывать аспект результативности, аспект экономической эффективности системы и другие аспекты эффективности, которые будут актуальны в каждом конкретном случае. Отметим еще несколько выводов, сформулированных в статье [1]:

• эффективность системы меняется при изменении потребностей сторон или других условий, ее оценка справедлива для конкретного периода времени;
• эффективность ИС (или иной системы, например, коммуникационной) в большинстве случаев невозможно оценивать как «эффективность ИС самой по себе», можно говорить только об оценке вклада этой ИС в достижение целей организации, региона или даже страны.

Такой подход к трактовке понятия «эффективность» вполне подтверждается содержанием актуальных международных стандартов на процессы жизненного цикла ИС и программных продуктов (ISO/IEC 12207 [2]) и систем более общего характера (ISO/IEC 15288 [3]), первые редакции которых уже давно действуют в качестве ГОСТ Р.

Стандарты, связывающие эффективность с жизненным циклом систем

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

Достаточно простая схема работы с эффективностью предусмотрена в стандартах комплекса ГОСТ 34 и оказавшемся связанным с ними еще более старом стандарте ГОСТ 24.202:80 [4]. Далее эти стандарты будем условно называть «старыми». Такой документ, как ТЭО (технико-экономическое обоснование), до сих пор включают в состав основанной на них общесистемной документации. Однако схема работы, предлагаемая старыми стандартами, уже давно является слишком ограниченной.

Гораздо больше возможностей дают современные, «новые» стандарты программной и системной инженерии. Здесь мы рассмотрим упоминавшиеся выше стандарты ISO/IEC 12207 и ISO/IEC 15288. Но не будем скрывать и того, что при полноценном использовании их возможностей придётся решать сложные организационные и методические вопросы. Более того, история официального действия первых редакций этих стандартов в качестве ГОСТ Р показала, что разрыв между их потенциальными возможностями и реально существующей профессиональной культурой, основанной в лучшем случае на старых стандартах, для большинства организаций оказывается очень большим. Эту пропасть не удается преодолеть «одним прыжком», целесообразно планировать совместное использование старых и новых стандартов, их согласование и поэтапное развитие.

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

Особенности работы с эффективностью в рамках ГОСТ 34 («старых» стандартов)

Основные стандарты комплекса ГОСТ 34 [5—8] активно используются и сегодня. И несмотря на известную архаичность и полное отсутствие многих компонентов, по ряду рациональных причин они будут использоваться еще значительное время. Эти стандарты кладутся в основу разбиения работ ЖЦ на стадии и этапы, составления планов выполнения работ в ЖЦ (как минимум по созданию и развитию систем), а также определения состава и содержания документации проектов создания и развития АС. Документами, на основании которых принимается большая часть основополагающих решений в ЖЦ АС, на практике в первую очередь являются техническое задание (ТЗ) и «Программа и методика испытаний». Их знают практически все руководители проектов АС и ИС: на основе ТЗ осуществляется планирование работ по созданию (развитию) системы, на основе ТЗ и «Программы и методики испытаний» проводится приемка системы в конце проекта. Более того, именно ТЗ кладется в основу контракта на собственно проектирование, реализацию, испытания и разворачивание АС. Заметим, что поскольку в одной статье невозможно описать все варианты формирования наборов контрактов и схем работ с эффективностью, даже если опираться только на старые стандарты, мы рассматриваем некоторую упрощенную ситуацию.

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

В частности, первые оценки эффективности системы и критерии ее определения даются на стадии «Формирование требований к АС», на которой ГОСТ 34.601—90 требует:

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

При исполнении последнего пункта потенциально могут учитываться самые современные требования к организации контроля эффективности системы на протяжении всего ее ЖЦ (хотя эта возможность активно не используется). На данной стадии РД 50-34.698—90 предусматривает, что разрабатывается специальный раздел «Ожидаемые технико-экономические результаты создания АС». На следующей стадии работ все показатели эффективности могут быть уточнены. Это естественно, так как выбирается вариант реализации системы и детализируются способы ее создания. Так, ГОСТ 34.601—90 определяет, что на этапе «Разработка вариантов концепции АС» в числе прочего оцениваются эффекты, получаемые от системы.

Наконец, ГОСТ 34.602—89 предусматривает, что в ТЗ, на основании соответствия которому система будет разрабатываться или приобретаться, испытываться и приниматься заказчиком, приводятся:

• наименования и требуемые значения технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания АС;
• критерии оценки достижения целей создания системы.

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

• виды, состав, объем и методы испытаний системы и ее составных частей;
• общие требования к приемке работ по стадиям.

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

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

• по ГОСТ 34 проводится сравнение на соответствие требованиям к системе, содержащимся в ТЗ, а не потребностям пользователей, которые как бы «остаются за бортом»;
• с момента разработки концепции и ТЗ до сдачи АС проходит значительное время, за которое многое может измениться — от нормативной базы до состава ключевых заинтересованных лиц, а испытания и сравнения делаются на соответствие требованиям к АС, составленным на основе прежних потребностей и условий (используемых технологий, ограничений и т. п.).

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

Особенности работы с эффективностью в рамках «новых» стандартов ИСО/МЭК 12207 и ИСО/МЭК 15288

Уже первые редакции стандартов [2] и [3] дали заказчикам большие дополнительные возможности по обеспечению эффективности систем. В версиях 2008 года произведен ряд уточнений, однако основные правила обеспечения эффективности АС и ИС сохранились. Дадим общую картину отличий работы с эффективностью по новым стандартам.

1. Отсутствие термина «эффективность системы». В новых стандартах данный термин в явной форме не вводится и в тексте активно не используется. Вместо этого на всем пространстве стандартов говорится об эквивалентных свойствах системы — соответствии потребностям заинтересованных лиц, определенным на их основе требованиям к системе, ограничениям на её создание и эксплуатацию. При этом используются указания на отдельные аспекты потребностей, требований и ограничений, например, затраты на создание системы или риски при ее создании и использовании. Свои трудности может создавать уже то, что не определяется, формальный состав документа, аналогичного ТЭО, не упоминается ничего подобного «экономической» или «социальной» эффективности. Но это — далеко не самая большая трудность в применении новых стандартов.

2. Работа в контексте предприятия. Новые стандарты предусматривают процесс «Управление портфелем проектов», в рамках которого принимаются решения:

• об отборе тех инициатив, в реализацию которых будут вкладываться ресурсы предприятия, и о переходе к запуску соответствующих проектов и их финансировании;
• о продолжении, переориентации или прекращении каждого из идущих проектов.

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

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

• определяются цели и стратегия приобретения, критерии соответствия приобретаемой системы (или программного продукта, или сервиса) потребностям, требованиям и ограничениям;
• разрабатывается контракт, ясно определяющий ожидания, ответственность и финансовые обязательства как заказчика, так и поставщика;
• выбирается поставщик (поставщики), приобретается продукт или услуга, отвечающая потребностям заказчика;
• работа по приобретению подвергается мониторингу для контроля выполнения предусмотренных ограничений, и в случае успеха производится приемка поставляемого продукта, а пункты контракта закрываются как успешные. При выполнении этого процесса есть возможность:
• учесть в контракте все необходимые аспекты и показатели эффективности;
• предусмотреть все необходимые режимы и процедуры периодической или ситуационной оценки эффективности;
• проводить эти оценки не дожидаясь не только конца проекта создания системы, но и завершения стадий и этапов, предусматриваемых моделью ЖЦ системы.

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

4. Адаптация стандартов для учета специфики предприятия и проекта. Дело в том, что процессы, описанные в указанных современных стандартах, представляют собой универсальные обобщенные наборы работ, которые могут инициироваться многократно в одном проекте или для одной ИС, по разным причинам и из различных других процессов. Поэтому такие «абстрактные» описания процессов и входящих в них работ не являются тем определенным «местом», где можно легко фиксировать конкретные моменты оценки эффективности в ходе выполнения конкретного контракта. Но не зря же говорится о том, что все предприятия и проекты разные (конечно, за рамками того, в чем они одинаковые!).

По этой причине сами новые стандарты предусматривают два уровня своей адаптации:

• в рамках учета специфики предприятия (организации) в целом;
• для учета специфики конкретного проекта.

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

• обсуждается идея системы, ее связи с целями предприятия, проектируются основные показатели ее эффективности;
• определяются ограничения на создание и функционирование системы, выбираются методы управления рисками в проекте её создания/внедрения;
• формируется модель жизненного цикла системы как схема стадий и этапов, нагруженная выбранными из стандарта процессами и работами; при этом как схема компоновки и последующего выполнения стадий и этапов, так и состав процессов и работ для каждой стадии и этапа могут требовать адаптации и быть уникальными в каждом проекте;
• составляется, обсуждается и заключается контракт, не просто учитывающий, но явно отражающий описанную выше уникальную модель жизненного цикла, тем или иным образом включающий в себя показатели эффективности системы, точки и условия выполнения различных контрольных процедур, в том числе оценки планируемых, а затем и реально достигаемых показателей эффективности приобретаемой системы (практически в этом случае контракт опирается на адаптированный под данный проект текст стандарта);
• контракт выполняется, а предусматриваемые в нем работы по мониторингу и оценкам позволяют как можно раньше выявлять любые несоответствия и исправлять их;
• исправления несоответствий проводятся на нескольких уровнях — в технических процессах (проектирование, реализация), в процессах управления проектом, в процессе управления портфелем проектов.

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

Совместное использование старых и новых стандартов

В заключение стоит обратить внимание на следующее. Поскольку применение новых стандартов для многих предприятий оказывается делом сложным, а использование только старых — недостаточным, целесообразно опираться на совместное применение стандартов старых и новых. Первый опыт и первые рекомендации по этому поводу излагались в [9]. С тех пор прошло более десяти лет, но практика показала, что выраженная в той статье общая идея остается работоспособной, так что её можно рекомендовать и сегодня.

Литература

1. Зиндер Е. З. Что такое «эффективность ИТ»// Intelligent Enterprise, 2006, № 8.
2. ISO/IEC 12207:2008. Systems and software engineering — Software life cycle processes.
3. ISO/IEC 15288:2008. Systems and software engineering — System life cycle processes.
4. ГОСТ 24.202:80. Требования к содержанию документа «Технико-экономическое обоснование создания АСУ».
5. ГОСТ 34.602—89. Техническое задание на создание автоматизированной системы.
6. ГОСТ 34.601—90. Автоматизированные системы. Стадии создания.
7. РД 50-34.698—90. Автоматизированные системы. Требования к содержанию документов 8. ГОСТ 34.603—92. Виды испытаний автоматизированных систем.
9. Зиндер Е.З. Соотнесение и использование стандартов организации жизненных циклов систем// СУБД, 1997, № 3.