Библиотека управления

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

М. Аншина Заместитель председателя правления фонда ФОСТАС
В. Бузмаков Президент АОЗТ «Супремум»
Журнал «Корпоративные системы» (Киев), № 1 за 2007 год
      Прочитав название статьи1, многие читатели могут сказать: «Ну вот, опять много непонятных слов и, скорее всего, ни о чем». Такая реакция вполне понятна — каждое из понятий, вошедших в название статьи, достойно отдельного достаточно тщательного и обширного рассмотрения.

Действительно, сегодня очень много статей и исследований посвящено стандартам и их применению, проектам и их применению, информационным технологиям и их применению в жизни конкретных предприятий. Самый сложный и проблемный вопрос как раз и заключается в том — нужно ли применять все эти знания в практической работе предприятий? Если нужно, то какие именно, каким образом, в каком объеме и для решения каких задач?

Самое интересное, что исторически эти области знаний начали развиваться примерно в одно время — в середине ХХ-го века. В самом начале они развивались достаточно обособлено. Но всем областям знаний и технологиям присуще расширение как предмета исследования, так и сфер их применения. В результате сегодня мы имеем следующую ситуацию (один из примеров «абракадабры»): для внедрения корпоративной информационной системы (КИС) применяются проектные методы, которые, в свою очередь, используют информационные технологии (например, систему управления проектами), а для постановки задачи по внедрению КИС нужны стандарты деятельности предприятия. Внедрение КИС неизбежно требует пересмотра стандартов деятельности предприятия, для чего опять-таки используются проектные методы…

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

Сегодня есть данные исследований, говорящие о том, что:

  • только 15–20% проектов заканчиваются вовремя и в срок;
  • 25–35% проектов завершаются неудачей;
  • 50–60% проектов выросли в цене более чем на 90%;
  • в завершенных проектах только 50–60% требований были реализованы;
  • около 60% инвестиций в ИТ убыточны или имеют нулевой эффект.

Даже руководители ИТ-подразделений удивляются неэффективности проектов!

Тем не менее, ИТ все более прочно входят в жизнедеятельность предприятий. И, судя по всему, проектов по внедрению ИТ будет становиться все больше и больше.

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

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

Таблица 1. Проекты: проблемы и факторы успеха

Основные проблемы проектов

Факторы, способствующие успеху проекта

  • недостаточное внимание руководства предприятия — 40%
  • отсутствие четких целей — 17%
  • хаотические бизнес-процессы — 14%
  • неготовность к изменениям — 12%
  • нестабильность законодательства — 6%
  • коррупция — 5%
  • низкая квалификация кадров на предприятии — 4%
  • недостаточное финансирование — 2%
  • участие руководства предприятия в проекте — 20%
  • наличие и соблюдение плана внедрения — 19%
  • ясные цели и четкие требования — 16%
  • участие специалистов клиента — 16%
  • качество системы и команды консультантов — 11%
  • реинжиниринг бизнес-процессов до внедрения — 8%
  • наличие стратегии у клиента — 8%
  • получение быстрой и эффективной отдачи от проекта — 2%

Из приведенной информации несложно сделать вывод, что основные проблемы ИТ-проектов лежат в области недооценки влияния ИТ на деятельность предприятия и изменений, вызываемых проектом внедрения ИТ. Соответственно возникает недооценка величины сопротивления этим изменениям.

Влияние стандартизации на успех ИТ-проектов

Использование стандартов в реальных проектах может оказать как положительное, так и отрицательное влияние на результат проекта — все зависит от того, кто и как использует стандарты. Если «инструмент» находится в умелых руках, то можно ожидать:

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

В то же время излишняя «зарегулированность» может не дать проекту динамично развиваться и даже привести к его краху.

Следует заметить, что роль стандартов на разных стадиях развития системы управления предприятием и на разных стадиях ИТ-проекта различна.

Отечественным предприятиям на данном этапе их развития наибольший эффект дает использование стандартов на ранних стадиях — на стадиях выбора и планирования проекта. Это обосновано тем, что ИТ-проекты — это особый вид проектов, они не являются «стандартным» видом деятельности даже для проектно-ориентированных компаний. То есть любая компания, начинающая ИТ-проект, сталкивается с ситуацией полной неопределенности — а что будет происходить с проектом? Как он будет развиваться? К чему приведут изменения?

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

При этом стандарты являются взаимовыгодным решением, которое удовлетворяет потребности как клиента (заказчика проекта), так и исполнителя.

Для заказчика стандарты проекта:

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

Для исполнителя стандарты проекта:

  • повышают шансы на выигрыш конкурса;
  • позволяют использовать мировой опыт;
  • улучшают взаимодействие с различными группами сотрудников в компании-заказчике;
  • повышают управляемость проекта;
  • позволяют организовать передачу опыта между проектами;
  • дают консультантам инструменты внедрения.

Проблемы стандартизации в ИТ

В то же время существуют проблемы создания стандартов в области ИТ. Это обусловлено:

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

Чтобы хоть немного «сгладить» ситуацию с наличием множества стандартов, международные и российские (увы, не украинские) организации ведут работу по гармонизации стандартов.

Отечественные стандарты в области ИТ

  • ГОСТ 34.003–1990 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения»;
  • ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы (АС)»;
  • ГОСТ Р 34.10 (процессы формирования и проверки электронной цифровой подписи);
  • РД 50–34.698–90 «Требования к содержанию документов» и др.;
  • ГОСТ Р 51954 (профиль прикладной среды организации вычислений на суперЭВМ);
  • ГОСТ РВ 51987 «Информационная технология. Комплекс стандартов на автоматизированные системы. Типовые требования и показатели качества функционирования информационных систем. Общие положения»;
  • Р 50.1.041 (Руководство по проектированию профилей среды открытой системы (СОС) организации-пользователя);
  • Р 50.1.027 (Автоматизированный обмен технической информацией. Основные положения и общие требования);
  • Р 50.1.028 (Методология функционального моделирования).

Гармонизированные стандарты — это эквивалентные стандарты, другими словами — стандарты, относящиеся к одному и тому же предмету, но утвержденные разными стандартизирующими организациями, которые устанавливают взаимозаменяемость продуктов, процессов и услуг или взаимное понимание результатов тестирования/ информации, предоставляемой в соответствии с этими стандартами.

Отметим, что в этом определении гармонизированные стандарты могут различаться на презентационном уровне и даже по существу, т. е. в объяснениях, руководствах, как соответствовать требованиям стандарта, предпочтениям по альтернативам и вариантам, но при этом они не должны противоречить друг другу (ISO/IEC Guide 2:1996). Обычно гармонизированные стандарты дополняют друг друга.

Таблица 2. Процессная и проектная таблица деятельности в области ИТ
 

Процессы

Проекты

Общие BPR, TQM PMBOK
Модели BPM, IDEF, ARIS, UML Диаграммы Ганта, WBS
ПО ITIL, ISO/IEC 12207, ISO/IEC 15288 XP, SWEBOK
Данные COBIT Стандарт информационной безопасности ISO 17799
Инфраструктура и сети eTOM, ITIL  

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

Давайте рассмотрим стандарты проектной деятельности.

Стандарты проектной деятельности в ИТ

Стандарты проектной деятельности в области ИТ укрупненно можно разделить на две части:

  • разработка программного обеспечения — ГОСТ 34, PRINCE22, SWEBOK и др.;
  • внедрение программных систем — методологии вендоров, PMBOK и др.

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

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

Проблемы отечественной стандартизации. Есть некоторые особенности отечественной стандартизации в области ИТ:

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

Кроме того, свой отпечаток накладывает и «историческое наследие», прежде всего это:

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

Проблемы международной стандартизации. Международные стандарты, увы, не являются «панацеей» ввиду того, что они создавались и совершенствовались абсолютно в других культурах информационных технологий и стандартизации. Кроме того, очень существенным является «языковой барьер». В области стандартов «обычные» правила перевода не работают! Каждое слово приобретает особую силу и значение, и даже незначительная ошибка переводчика может привести к катастрофическим последствиям. Все это усложняется еще и тем фактом, что длительная изоляция стала причиной того, что освоить все обилие и многообразие стандартов сразу просто физически невозможно.

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

  • не учитывается связь бизнеса и ПО;
  • упор делается на разработку (доработку), а не на внедрение. На настоящий момент не существует отечественных методик и/или стандартов (ГОСТов) в области внедрения готовых приложений;
  • поверхностные знания стандартов;
  • как следствие, их неправильное употребление.

Какие стандарты использовать

Как уже отмечалось, сегодня существует достаточно много стандартов, в той или иной мере имеющих отношение к ИТ-проектам. Закономерно возникает вопрос — какие из них использовать? И как? Ведь каждый из них в какой-то мере является самодостаточным, и в то же время часто они дополняют и расширяют друг друга.

Ответ на этот вопрос очень прост — нужно использовать те стандарты, которые понятны предприятию и соответствуют его культуре как в области ИТ, так и в области стандартизации. Объяснение следующее: то, что непонятно, никогда не будет использовано по назначению.

Методики ведения проекта внедрения

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

Основные отечественные стандарты ведения проектов ИТ:

  • ГОСТ 19.001–77 (Единая система программной документации — 01.01.1980 г., переиздание — ноябрь 1987 г.);
  • ГОСТ 24;
  • ГОСТ 34;
  • ГОСТ 34.003 — 90. Термины и определения.

Наиболее популярные методологии вендоров:

  • SAP — ASAP (ValueSAP);
  • Oracle — AIM (Applications Implementation Method);
  • J D Edwards — OneMethodology;
  • BAAN — Target.

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

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

  • улучшить показатели внедрения;
  • повысить ценность продукта;
  • приобрести конкурентное преимущество;
  • дать инструмент партнерам-консультантам.

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

К основным критериям выбора стандарта внедрения необходимо отнести:

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

Отечественные стандарты (ГОСТ 34 и другие): pro и contra. Сегодня наиболее распространенными являются все-таки отечественные стандарты (ГОСТ 34 и др.). Как правило, они применяются организациями, имеющими длительную историю использования ИТ. Использование этих стандартов дает определенный эффект, и, безусловно, это лучше, чем отсутствие какого бы то ни было стандарта. Но возраст этих стандартов объективно привел к тому, что они во многих требуемых областях недостаточны, а в других — избыточны.

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

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

Основные этапы создания собственного корпоративного стандарта:

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

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

Зачем нужны стандарты

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

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

Нужно также учитывать, что в любом проекте есть свои нюансы и особенности, поэтому стандарты не следует применять слепо, их надо использовать «как образец», как ориентир в современном мире ИТ.


1 Статья написана по материалам V консультационно-практической конференции «Современные концепции управления предприятием и информационные технологии» (Киев, 2006).

2 Методология управления проектами PRINCE/PRINCE2 является де-факто стандартом в Великобритании, и ее применение обязательно в государственных проектах. Название методологии является аббревиатурой от Projects In Controlled Environments и отражает ее предназначение — управление проектами и группами проектов внутри организации.