3.1. Понятие качества и его многомерность

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

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

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

Для расстановки приоритетов качества на каждом этапе жизненного цикла внедрения ИТ необходимо учитывать следующие вопросы:

1. Готова ли компания запустить приложение в эксплуатацию и все ли бизнес-процессы работают так, как было запланировано?

2. Обеспечены ли прозрачность и контроль над изменениями в приложении?

3. При возникновении проблем в эксплуатации можно ли их быстро выявить и устранить?

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

Говоря о качестве ИТ-проекта, следует отметить, что не существует единой метрики качества. Это объясняется тем, что не всегда можно однозначно ответить на вопрос, какие характеристики важнее – применение ПО, его производительность, результаты использования, стоимость и время разработки или же удовлетворение коммерческим требованиям.

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

Рис. 7. Пример метрик качества ПО

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

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

• устойчивость к сбоям (Robustness) – уровень, до которого система продолжает корректно выполнять свои функции, несмотря на неверный ввод данных, недостатки подключенных программных компонентов или компонентов оборудования;

• производительность (Performance) – характеристика того, насколько быстро и качественно система должна выполнять определенные операции;

• взаимодействие (Interoperability) – каким образом система, приложение или сервис обменивается данными с другими системами, приложениями, сервисами;

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

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

• доступность (Availability) – запланированное время доступности, в течение которого система действительно доступна для использования и полностью работоспособна;

• целостность и защищенность (Integrity) – возможность блокировки неавторизованного доступа, предотвращение потери или порчи информации, сохранение конфиденциальности информации.

Для разработчиков и ИТ-персонала, как правило, важны другие атрибуты качества:

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

• легкость эксплуатации (Maintainability) – насколько удобно исправлять ошибки или модифицировать систему, то есть трудозатраты на эксплуатацию, устранение ошибок;

• переносимость (Portability) – усилия, необходимые, чтобы перенести систему из одной аппаратной или программной среды в другую;

• возможность повторного применения (Reusability) – насколько данный продукт может быть использован в другом применении;

• способность к тестированию (Testability) – усилия, необходимые, чтобы убедиться в соответствии выполняемых функций установленным требованиям и соответствующим трудозатратам;

• масштабируемость – насколько легко наращивать количество пользователей или объемы данных в системе.

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

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

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

3.2. Основные проблемы и ключевые факторы успеха ИТ-проектов

 

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

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

По статистике Standish Group, причины неудач ИТ-проектов заключаются в следующем:

1) неполные требования;

2) недостаточная вовлеченность пользователей;

3) нехватка ресурсов;

4) нереалистические ожидания;

5) недостаточная поддержка руководства;

6) изменение требований и спецификаций;

7) недостаточное планирование;

8) технологическая некомпетентность персонала;

9) нехватка квалифицированных менеджеров проектов.

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

Таблица 2.

Причины неудач ИТ-проектов и способы их предотвращения 

Рассматривая проблемы при внедрении ИТ-проекта, следует разделять проблемы:

• на этапе принятия решения о внедрении ИТ и выбора программного продукта;

• на этапе планирования ИТ-проекта;

• на этапе внедрения ИТ.

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

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

Эффективным способом устранения множества проблем на этапе принятия решения о выборе и целесообразности внедрения ИТ является проведение обследования предприятия на предмет выявления и документирования первоочередных задач, которые должна выполнять новая технология или система. Целесообразны определение структуры и исходного состояния объекта автоматизации, определение масштабов и сложности внедрения ИТ.

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

На этапе внедрения ИТ выявлено наибольшее количество проблемных областей, а именно:

• отсутствие упорядоченных, формализованных бизнес-процессов или их недостаточная формализация;

• отсутствие в компании единой нормативно-методологической базы;

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

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

• сопротивление всего или значительной части персонала самому внедрению и сопутствующим нововведениям;

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

• затрудненная интеграция ИТ-системы с уже имеющимися на предприятии системами автоматизации управления.

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

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

3.3. Влияние изменений на риски ИТ

Главными источниками ИТ-рисков считаются большой объем изменений, возрастающая сложность систем, а также бреши в системах безопасности, которыми пользуются хакеры, – говорится в отчете HP за 2008 год по результатам глобального исследования, в котором приняли участие 1125 ИТ-специалистов из 20 стран. Один из четырех респондентов констатировал, что 50 % вынужденных простоев обусловлены изменениями. Это значит, что для многих ИТ-организаций жизненно необходимы предсказуемость их деятельности и управление изменениями. Добиться успеха смогут лишь те компании, которые, реагируя на перемены, быстрее других приспосабливаются к новым условиям – бизнес-процессам, технологиям, стандартам качества, способам коммуникаций и прочему.

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

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

Рис. 8. Зависимость изменений от ЖЦ проекта

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

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

Также изменения могут быть связаны с технологией работы и реализации проекта. ИТ-отрасль очень динамична и находится в постоянном развитии. Новые технологии и подходы, а также новое оборудование появляются стремительно, на порядок быстрее, чем в других более традиционных областях (например, строительстве). Таким образом, в ходе реализации ИТ-проектов часто меняются подходы к разработке – появляются новые технологии, языки программирования, платформы или принимается решение по использованию новых технологий. Обновляются версии базового программного обеспечения, операционных систем и сред, СУБД и прочего.

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

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

Говоря об управлении изменениями ИТ-проекта, прежде всего нужно обратить внимание на своевременную идентификацию и формализацию изменений в процессах и организационной структуре компании при внедрении ИТ. Формализация включает описание изменения, установление причины, анализ последствий от внедряемого изменения, план мероприятий по управлению изменениями. Для контроля изменений рекомендуется:

• создавать и поддерживать базу данных конфигураций основных компонентов ИТ-системы;

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

• декомпозировать большие изменения до уровня «влияние на 1 компонент» или «выполняется одним человеком». Это позволит достаточно просто связывать задания на разработку с запросами на изменения;

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

• помимо менеджера ИТ-проекта и представителей заказчика, привлечь таких членов команды, как менеджер по качеству (Quality Assurance), главный аналитик (архитектор) проекта, ответственный за интеграцию.

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

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

3.4. ИТ-аудит как средство управления рисками

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

Можно выделить различные виды ИТ-аудита, которые отличаются по своим задачам и конечным результатам:

1) регулярный независимый внешний ИТ-аудит: необходим по требованию законодательства (ЦБ РФ, Гостехкомиссия РФ, закон Сарбсинса-Оксли);

2) регулярный внутренний ИТ-аудит: инициируется высшим руководством для повышения эффективности работы компании и оценки затрат на ИТ;

3) специальный ИТ-аудит: инициируется руководством и проводится перед важными организационными изменениями (IPO, слиянием и прочим).

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

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

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

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

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

1) риски информационной безопасности, которые определяются моделью бизнеса и заключаются в повышенных требованиях к конфиденциальности всей внутренней информации, находящейся в системах учета, электронной почте, пользовательских файлах;

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

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

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

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

Целью аудита информационной безопасности являются:

• оценка текущего уровня защищенности ИТ;

• выявление рисков и уязвимостей в системе защиты;

• анализ угроз, которые могут быть реализованы через обнаруженные уязвимости;

• оценка соответствия требованиям системы информационной безопасности;

• выработка рекомендаций по внедрению новых и повышению эффективности существующих механизмов безопасности, а также по приведению в соответствие требованиям системы информационной безопасности.

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