Проблемы использования информационной системы управления

Процессы жизненного цикла ИСУ

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

Поэтому реализация этих процессов является одной из актуальнейших задач для предприятия. Их важность подчеркивает и тот факт, что они входят как в стандарт 12207, так и в 15288.

Рассмотрим вспомогательные процессы жизненного цикла (ЖЦ) (организационные процессы сознательно не рассматриваются в статье, так как заслуживают отдельного внимания и реальную помощь в их реализации способна оказать методология управления проектами).

⇒ Информационные технологии предприятия (ИСУ)

Документирование — процесс фиксирования информации, которая создается в рамках ЖЦ. Приведем два примера, характеризующих важность документирования.

Пример 1. Поставщики програмного обеспечения (ПО), системные интеграторы, консалтинговые компании при конфигурации проекта и расчете его стоимости уделяют особое внимание наличию актуальной и полной документации. При ее отсутствии стоимость и продолжительность проекта, как правило, увеличиваются на 15–20%.

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

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

Управление конфигурацией — процесс применения на протяжении всего ЖЦ ИСУ административных и технических процедур по идентификации элементов ИСУ, управлению модификацией элементов, фиксированию состояния элементов, подготовки отчетов и регистрации запросов на модификацию, обеспечению интеграции элементов ИСУ.

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

Верификация (подтверждение выполнения заданных требований) — процесс определения, насколько соответствуют первоначальным требованиям произведенные модификации ИСУ. Целесообразно данный процесс объединять с процессами поставки, разработки, эксплуатации или сопровождения элементов ИСУ. Разделяют верификацию контрактов, требований и верификацию проектов.

Верификация контрактов состоит в установлении того, что:

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

Верификация требований состоит в установлении того, что:

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

Верификация проектов состоит в установлении того, что:

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

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

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

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

Аудит (ревизия, которая производится уполномоченным лицом с целью обеспечения независимой оценки продуктов проекта, что бы оценить их соответствие требованиям) — процесс определения согласованности с требованиями, планами и контрактом. Он состоит в оценке:

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

Решение проблем — процесс осуществления анализа и решения проблем, которые возникают во время разработки, эксплуатации и сопровождения ИСУ (независимо от их природы или источника). Цель этого процесса — обеспечение своевременных, ответственных и задокументированных способов выявления, анализа и решения проблем, а также определения их тенденции.

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

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

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

⇒ Информационные технологии: жизненный цикл ИСУ

Практика

Автор надеется, что приведенный далее пример реализации процесса решения проблем (пример 1) поможет читателю на практике приступить к внедрению процессов ЖЦ ИСУ.

Предвидя закономерный вопрос «кто же все это будет делать?», в примере 2 приводится структура ИТ-департамента, на чьи плечи можно возложить тяжелую ношу реализации ЖЦ ИСУ.

Пример 1. Решение проблем

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

Далее приводится пример реализации процесса решения проблем. Он в некотором смысле универсальный, так как разработан на основании методологии управления проектами и ДСТУ 3918-1999, хотя в отдельных случаях нуждается в адаптации.
Следует заметить. что внедрение процесса решения проблем связано со сложностями организационного характера и требует решимости от менеджеров.

Решение каждой проблемы проходит четыре стадии:

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

Для обеспечения замкнутости процесса решения проблем закрепляется персональная ответственность лица, идентифицирующего проблему, за приемку результатов ее решения.

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

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

В случае обнаружения проблемы другими сотрудниками предприятия они должны обращаться к своим непосредственным руководителям.

При выявлении проблем сторонними организациями Ответственное лицо (это может быть либо начальник АСУ, либо начальник службы качества) должно произвести анализ проблемы и предоставить его результаты своему непосредственному руководителю. В этом случае Инициатором будет считаться Ответственное лицо или его руководитель.
В момент регистрации каждая проблема должна быть задокументирована при помощи, разработанных и утвержденных на предприятии Форм Регистрации Проблем. Заполнение формы (либо проверку правильности ее заполнения) производит Ответственное лицо. Все проблемы должны регистрироваться Ответственным Лицом.

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

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

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

• Отклонена. Проблема отклоняется, если она не препятствует деятельности предприятия, либо может быть решена собственными силами отдела АСУ в рабочем порядке. Перед тем как отклонить проблему, необходимо обсудить это решение с лицом, идентифицировавшим ее. Это позволит инициатору еще раз сформулировать суть проблемы, и, возможно, более удачно передать ее важные аспекты.

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

• Объединена. Проблемы, тесно связанные между собой, должны быть объединены. При объединении одна из проблем закрывается, а описание другой проблемы изменяется с учетом произошедшего объединения.

• Принята. Для принятых проблем производится рассмотрение и оценка альтернатив решения, выбор альтернативы и назначение исполнителя для ее решения.

Проблемы должны оцениваться по степени своего влияния на деятельность предприятия, а также по типу, масштабам, критичности по следующим категориям важности:

• высокая — такие проблемы должны быть рассмотрены и утверждены высшим руководством;

• средняя — такие проблемы должны быть рассмотрены и решены начальником отдела АСУ совместно с кем-либо из менеджеров среднего звена;

• низкая — такие проблемы должны быть рассмотрены, и решения по ним приняты начальником отдела АСУ самостоятельно (обычно проблемы такого рода не имеют альтернативных решений и их суть — в необходимости принять конкретное, заранее известное решение).

Как только по какой-либо проблеме принято решение, оно должно быть преобразовано в последовательность шагов по его реализации.

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

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

Пример 2. Структура ИТ-департамента

На рис. 3 показана типовая структура ИТ-департамента.

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

ЛИТЕРАТУРА

1. Б. Позин. Стандарты и методологии в жизненном цикле программного обеспечения информационных систем //Директор ИС— 2001.— № 10.
   
2. Н. Михайловский. Архитектура информационной системы, оценка рисков и совокупная стоимость владения //Директор ИС— 2001.— № 6.
   
3. A Successful Software Quality Strategy Using ISO/IEC 12207 &15288. (http://www.15288.com/)
   
4. Пуцко Владимир Васильевич директор по консалтингу, АОЗТ «Супремум» (г. Киев). vputsko@supremum.com.ua

Смотрите также

• Управление финансами
• Ключевые показатели эффективности
• Оптимизация бизнес-процессов
• Электронный документооборот
• Стратегическое управление
• Теория Ограничений (TOC)