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

SDLCПлан реализации проекта развития информационной системы (ИС) представляет собой сильно упрощенную интерпретацию методологии создания систем SDLC (System Development Life-Cycle) и ее V-модификации.

Методология создания систем SDLC

Рисунок 1. Методология создания систем SDLC

План проекта развития ИС

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

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

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



1.1 Формулирование целей проекта

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

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

1.2 Расчет ожидаемых преимуществ и определение верхней границы бюджета проекта

Ожидаемые бизнес-преимущества, приведенные к денежному эквиваленту в рамках 1-3-х-летнего периода (очень приближенно на данном этапе), определяют верхнюю планку бюджета проекта создания ИС, которая, как минимум, не должна превышать денежного эквивалента ожидаемых выгод.

1.3 Оценка осуществимости проекта

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

1.4 Формирование команды проекта

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

Со стороны Заказчика

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

Со стороны Исполнителя

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

2. Анализ информационных потребностей

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

2.1 Создание пользовательской спецификации ИС

Пользовательская спецификация должна описывать:

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

2.2 Разработка плана проверки пригодности ИС.

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

2.3 Принятие решения о способе создания системы

В зависимости от роли ИС, выбирается один из способов создания ИС (Оригинальная разработка (заказная или сделанная своими силами), приобретение готового решения, передача на аутсорсинг или др.).

2.4 Подготовка и проведение тендера на поставку/создание элементов ИС.

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

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

Технический дизайн осуществляется аналитиками Исполнителя при непосредственном участии членов экспертного совета Заказчика.

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

3.1 Создание Системной спецификации.

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

3.2 Написание Руководств пользователей

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

3.3 Разработка Плана технического тестирования системы и отдельных ее элементов

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

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

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

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

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

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

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

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

6.1 Обучение пилотной группы пользователей процедурам работы с ИС.

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

6.2 Полномасштабное функциональное тестирование.

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

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

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

7.1 Планирование и организация обучения пользователей ИС

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

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

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

7.3 Планирование, согласование и реализация изменений в процессах информационного взаимодействия с партнерами

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

7.4 Разработка и реализация плана ввода в эксплуатацию новой ИС

План ввода новой ИС в эксплуатацию должен предусматривать:

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

7.5 Разработка механизмов мониторинга результативности и эффективности новой ИС

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