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

Вид материала

Документы

Содержание Внешние задачи Задачи переходного периода Методологии управления проектами Рис.2 V-модель управления проектом внедрения ИКТ Организационный уровень Инициация проекта Анализ потребностей Технический дизайн Создание системы Техническое тестирование Функциональное тестирование Внедрение системы и ее эксплуатация Рис.3 Способы внедрения ИКТ Параллельное внедрение Пилотное и пошаговое внедрение Альтернативные методологии Рис.4 Связь альтернативных методов с SDLC Приобретение готовых решений Использование услуг сторонних организаций (Outsourcing) Создание систем конечными пользователями (End-user computing) ... Полное содержание

Подобный материал:

• П. В. Терещенко Материалы к теме «Формирование организационной структуры» Формирование, 143.62kb.
• Теоретические основы совершенствования организационной структуры предприятия, 18.46kb.
• Уровни организационной культуры, 27.91kb.
• «организационная культура», 23.08kb.
• Разработка организационной структуры управления инновационным проектом, 59.96kb.
• Руководителю предприятия, 15.48kb.
• Концепция организационной конфигурации Эти универсальные блоки в том или ином виде, 112.43kb.
• План Введение С. 2 3 История изучения организационной культуры в науке С. 4 8 Типология, 451.39kb.
• Доклад тема дипломной работы: «Разработка проекта совершенствования организационной, 62.38kb.
• Программа 4 съезда амбулаторных хирургов РФ 1 день съезда, 150.96kb.

Управление проектом изменения информационной системы

Управление проектом, методологии, выбор решения.

Управление проектом внедрения ИКТ

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



Рис.1 Составляющие проекта внедрения ИКТ

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

Внутренние задачи:

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

Внешние задачи:

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

Задачи переходного периода

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

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

Методологии управления проектами

Методология Жизненного цикла (SDLC)

Одна из хорошо зарекомендовавших себя методологий управления проектами создания информационных систем - методология Жизненного цикла SDLC (System Development Life Cycle). Описание ее вариаций можно встретить во многих первоисточниках. Во многих странах (например в Германии и Бельгии), в качестве национальных стандартов, регламентирующих создание информационных систем принята V-модель жизненного цикла, которую мы и рассмотрим более подробно.



Рис.2 V-модель управления проектом внедрения ИКТ


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

Организационный уровень	Сфера ответственности
Топ-менеджеры компании или подразделения, в котором производится внедрение ИКТ	1. Инициация проекта 7. Контроль за внедрением и результатами проекта
Менеджеры и сотрудники подразделений	2. Анализ и формулирование информационных потребностей 6. Функциональное тестирование и эксплуатация системы
Менеджеры и руководители проектов ИТ-служб или сторонних организаций, привлеченных для работ по внедрению ИКТ	3. Технический дизайн 5. Техническое тестирование
Технические сотрудники ИТ-служб или привлеченных организаций	4. Техническое создание системы

Инициация проекта

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

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

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

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


Анализ потребностей

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

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

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

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

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

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


Технический дизайн

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

На основании пользовательской спецификации, с применением методик и средств технического и системного дизайна, на этом этапе создаются:

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

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

Создание системы

Собственно создание системы (изготовление компонент, сборка, программирование и т.д.) осуществляется под руководством менеджеров технических служб

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

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

Техническое тестирование

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

Функциональное тестирование

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

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


Внедрение системы и ее эксплуатация

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

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



Рис.3 Способы внедрения ИКТ

Все проиллюстрированные на Рисунке 3 разновидности внедрения новой системы встречаются в реальной жизни. Все имеют свои достоинства и недостатки, которые можно учесть и использовать при планировании процесса внедрения.

Параллельное внедрение

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

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

Пилотное и пошаговое внедрение

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

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

Переключение

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

Достоинства

Недостатки

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

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

Альтернативные методологии

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



Рис.4 Связь альтернативных методов с SDLC

Создание прототипа.

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

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

Приобретение готовых решений

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

Достоинствами этого подхода являются:

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

К числу основных недостатков относятся:

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

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

Использование услуг сторонних организаций (Outsourcing)

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

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

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

Создание систем конечными пользователями (End-user computing)

Аналогично Outsourcing–у, создание систем конечными пользователями, с одной стороны плохо управляемо, но, с другой стороны, более дешево и зачастую, самостоятельно создаваемые системы более эффективно удовлетворяют потребности самих пользователей. Для успешного применения этого подхода необходимо:

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

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

Выбор способа создания и управления проектом внедрения ИКТ

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

• Потенциальные системы
  

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

• Стратегические системы
  

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

• Ключевые системы
  

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

• Вспомогательные системы
  

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

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

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

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

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

но и множество неизмеримых показателей:

• Оптимизация управления ресурсами
  
• Возросшая гибкость
  
• Более своевременная, верная, адекватная и т.д. информация
  
• Рост профессионального уровня персонала
  
• Рост заинтересованности и удовлетворенности персонала
  
• Соответствие нормам
  
• Рост удовлетворенности клиентов
  
• Улучшение имиджа фирмы
  
• и др.
  

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

	Потенциальные ИС	Стратегические ИС	Ключевые ИС	Вспомогательные ИС
Инициация	Свободная и открытая. Некоторое ограничение средств	Тщательное, детальное планирование с применением инструментов стратегического анализа. Сильный менеджмент.	Следование за технологиями. Последовательное внедрение и следование стандартам. Педантичное управление проектом	Использование внешних служб, где возможно. Свобода пользователю.
Анализ потребностей	Неформальны, творческий. Применение прототипов	Креативный и широкий. Тщательное документирование и отслеживание результатов в контрольных точках	Полный по возможности. Особое внимание эффективности и совместимости	Ограничение лишь самыми необходимыми потребностями и изоляция от других систем.
Создание (Тех. дизайн, + создание, + тех.тестиро-вание)	Быстрое и итеративное. Использование экспертов для оценки потенциала и слабых мест	Инновационное, но тщательно спланированное и быстрое. Ограниченное использование прототипов.	По заказу или приобретение готовых решений где возможно. Внимание на эффективное расходование средств.	Избежание излишних усилий. Использование готовых решений, Outsourcing или создание пользователями
Проверка функциониро-вания	Неформальная	Хорошо спланированное с фокусом на удовлетворение бизнес-потребностей.	Всестороння, с фокусом на экономическую эффективность	Работает ли? Под ответственность пользователей.
Внедрение и эксплуатация	Пользователи должны полагаться на свою собственную оценку	Очень аккуратное, но быстрое и решительное. Тщательная подготовка персонала.	Тщательное, с обеспечением дублирования для гарантии верности результатов. Обеспечение совместимости с другими системами	Минимальные усилия лишь для обеспечения самостоятельности пользователей

Написание технического задания на создание/ изменение ИС

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

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

«Техническое задание является основным документом, в соответствии с которым проводят создание автоматизированной системы и приемку его Заказчиком» - это выписка из стандарта серии «Информационные технологии» (ГОСТ 34.602-89 «Техническое задание на создание автоматизированных систем»). Акт о приёмке выполненных работ по договору чаще всего составляется таким образом, что в нём отражаются результаты проверки выполнения требований ТЗ. Такой подход разумен, так как позволяет разрешать конфликтные ситуации, которые при разработке информационных систем и программных продуктов возникают намного чаще, чем при создании проектов другого назначения. Речь идёт конечно о технических заданиях, составленных качественно, то есть о таких, где Заказчик и Исполнитель одинаково трактуют предъявляемые требования. А что получается, в противном случае, иллюстрирует рис.1, где изображена картинка, обошедшая на заре разработки программных продуктов весь мир.



Рис.1. О значении правильного формулирования требований ТЗ

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

Роль детализированного ТЗ особенно велика на этапе приёмки работы, т.е. на том этапе, когда требуется формализация описания результатов работы: что выполнено в рамках договора, а что – нет. Этого требуют интересы обоих сторон. Как любят повторять опытные специалисты-разработчики информационных систем: «Аппетит приходит во время еды». Действительно, Заказчик в процессе работы над проектом «умнеет» и наращивает объём требований, предусмотренный требованиями Договора. При неконкретном ТЗ в таком случае пострадавшей стороной является Исполнитель. Он вынужден выполнять больший объём работ, чем планировалось по Договору. С другой стороны, не менее часто в роли пострадавшей стороны выступает Заказчик. Речь идёт о случаях, когда Исполнитель по самым разным причинам не стремится в ходе работы излишне уточнять требования Заказчика и многие вопросы решает так, как он их понимает. Так что, при приёмке работ конфликт интересов – обычное дело, и детализированное ТЗ помогает его разрешить.

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

Отечественные нормативные документы всегда уделяли большое значение ТЗ, не только, как документу, но и как важнейшему этапу (разработки, поставки), т.е. как процессу. Как показывает анализ, за рубежом вопросам ТЗ также уделяется серьёзное внимание, особенно в последние годы в рамках принятой сегодня во всём мире интегрированной модели качества CMMI (Capability Maturity Model Integration). В CMMI две области процессов посвящены работе с требованиями — «Управление требованиями» (Requirements Management) и «Разработка требований» (Requirements Development). Область процессов «Управление требованиями» подразумевает, что организация-Исполнитель получила требования от Заказчика, а область процессов «Разработка требований» — что организации-Исполнителю известны потребности Заказчика, но эти потребности должны быть трансформированы в требования к продукту (проекту). Общепризнанно, что CMMI - большая по объему и сложная для понимания модель. Тем не менее в рамках нашего курса мы обратимся к ней, чтобы продемонстрировать единство взглядов на формирование ТЗ в рамках CMMI и в рамках отечественных ГОСТов.

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



Рис. 2. Процесс разработки требований в соответствии с CMMI

По сути СММI рекомендует то, что почти всегда делалось в соответствии с ГОСТами советского периода: Этапу создания продукта (проекта) предшествовал этап проработки требований Заказчика, формализации его пожеланий качественного характера, а также согласования со всеми заинтересованными сторонами будущего проекта. Назывался этот этап аван-проектом, заканчивался аван-проект подготовкой ТЗ. На рис. 3 представлены основные стадии разработки проекта на создание информационной системы, рекомендованные отечественными нормативными документами. Этот рисунок иллюстрирует место появления «Технического задания» в жизненном цикле процесса разработки ТЗ. Но здесь необходимо отметить, что ТЗ не является жёстко зафиксированным документом. Как отмечалось выше, в него по ходу создания ИС могут вноситься изменения и дополнения. Достаточно часто в качестве приложения к ТЗ используется документ «Исходные данные», который в течение разработки проекта постоянно пополняется и совершенствуется.



Рис.3 Место «Технического задания» в процессе создания информационной системы (ИС).

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

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

• ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания. (Взамен ГОСТ 24.601-86, ГОСТ 24.602-86).
  
• ГОСТ 34.602-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы (Взамен ГОСТ 24.201-85)
  
• ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем (Взамен ГОСТ 24.104-85 в части разд. 3.)
  
• РД 50-34.698-90. Автоматизированные системы. Требования к содержанию документов. ГОСТ 19.102-77. Единая система программной документации. Стадии разработки.
  

На основании анализа перечисленных выше документов, предлагается следующий состав документа «Техническое задание на создание (развитие) ИС» для проектов внедрения ИКТ в компаниях малого и среднего бизнеса:

1. общие сведения;
   
2. назначение и цели создания (развития) ИС;
   
3. характеристика компании и «цепочки поставок»;
   
4. требования к ИС;
   
5. состав и содержание работ по созданию ИС;
   
6. порядок контроля и приемки ИС;
   
7. требования к составу и содержанию работ по подготовке компании к вводу ИС в действие;
   
8. требования к документированию;
   
9. источники разработки.
   

Раздел 1) «Общие сведения»:

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

Раздел 2) «Назначение и цели создания (развития) ИС»:

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

Раздел 3) «Характеристика компании и «цепочки поставок»

• краткие сведения о компании и о её « цепочке поставок» или ссылка на документы, содержащие такую информацию;
  
• сведения об условиях эксплуатации в офисе компании, где планируется установка программно-аппаратных средств ИС.
  

Раздел 4) «Требования к ИС»:

• требования к ИС в целом;
  
• требования к функциям (задачам), выполняемым ИС;
  
• требования к видам обеспечения.
  

В подразделе «Требования к ИС в целом» рекомендуется указывать:

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

В подразделе «Требования к функциям (задачам)», выполняемым ИС рекомендуется указывать:

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

В подразделе «Требования к видам обеспечения» в зависимости от вида ИС приводят требования к информационному, программному, техническому, организационному, методическому и другие видам обеспечения .

Раздел 5) «Состав и содержание работ по созданию (развитию) системы»:

• перечень стадий и этапов работ по созданию ИС,
  
• перечень документов, предъявляемых по окончании соответствующих стадий и этапов работ.
  

Раздел 6) «Порядок контроля и приемки системы»:

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

Раздел 7) «Требования к составу и содержанию работ по подготовке к вводу ИС в действие»

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

Раздел 8) «Требования к документированию» :

• требования к составу и содержанию отчётных документов
  
• требования к количеству
  
• тип носителя информации
  

Раздел 9) Источники разработки» :

• документы и информационные материалы, на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.
  

В состав ТЗ на создание (развитие) ИС желательно включать расчет (оценку) ожидаемой эффективности системы.

В качестве вывода необходимо отметить, что без детализированного ТЗ ни один проект не может быть успешно реализован. Возникает вопрос, насколько ТЗ на ICT-проект в большой компании отличается от ТЗ на проекты для малого и среднего бизнеса. Безусловно, отличия есть и связаны они и с «урезанием» количества требований ГОСТов в зависимости от масштаба компании, и с политикой «кусочной автоматизации», потому что на серьёзные информационные проекты не хватает финансов. Но даже в этих условиях при реализации самого простого проекта (например, при настройке «коробочного продукта» на «индивидуальность») необходимо формализовать постановку задачи, грамотно составив ТЗ.

Задания для групп. Составить

1. ТЗ на разработку сайта или Интернет-магазина (по выбору).
   
2. ТЗ на разработку информационной сети на базе файл-сервера.
   
3. ТЗ на настройку «коробочного продукта» CRM.
   
4. TЗ на настройку «коробочного продукта» из состава сетевой версии 1C.
   
5. ТЗ на строительство инфраструктуры офиса (активное и пассивное оборудование).
   

Обоснование выбора продукта, мультикритериальный взвешенный выбор

Методика Паттерн

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

Критерии сравнения (и их весовые коэффициенты)	Варианты информационных систем
	Продукт А	Продукт Б	Продукт В	Продукт Г
Функциональность (0,4)	0,3 х 0,4	0,4 х 0,4	0,6 х 0,4	0,3 х 0,4
Масштабируемость (0,2)	0,5 х 0,2	0,4 х 0,2	0,2 х 0,2	0,7 х 0,2
…	…	…	…	…
Результирующая оценка (1)	0,75	0,62	0,84	0,65

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

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

Методика ПАТТЕРН явилась важным инструментом анализа труднорешаемых проблем с большой неопределенностью, прогнозирования и планирования их выполнения. Основные идеи методики применялись в различных областях – научные исследования, проектирование и создание систем различной сложности, расширение рынков сбыта продукции.

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


Особенности процедуры оценки

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

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

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

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

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

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