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

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

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

Следующим шагом стала визуализация того, как именно люди будут использовать информационную систему. Для этого используется специальная UML диаграмма - USE CASE, предоставляющая в наглядной форме возможные действия пользователя, имеющего определённую роль.

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

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

Общая архитектура информационной системы

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

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

Существует несколько типов архитектур применяемых при разработке информационных систем - как то:

Настольная архитектура (рисунок 9);

Распределённая архитектура (рисунок 10).

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

Р и с у н о к 9 - Настольная архитектура приложения

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

Р и с у н о к 10 - Многозвенная архитектура с сервером приложений в качестве посредника

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

Преимущества системы:

Отсутствие дублирования кода программы-сервера программами-клиентами;

Так как все вычисления выполняются на сервере, то требования к компьютерам, на которых установлен клиент, снижаются;

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

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

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

Недостатки:

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

Поддержка работы данной системы требует отдельного специалиста -- системного администратора;

Высокая стоимость оборудования.

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

Разработка локальных хранилищ и базы данных на сервере это фактически отдельный этап проектирования системы, но в то же время их разработка является частью проектирования общей архитектуры. Так что следует упомянуть и эту часть информационной системы. Так, в качестве СУБД используется Microsoft SQL Server Express - бесплатная версия системы управления реляционными базами данных Microsoft SQL Server. Основным языком запросов этой СУБД является Transact-SQL, который является реализацией стандарта ANSI/ISO по структурированному языку запросов.

Р и с у н о к 11 - Архитектура ИС

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

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

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

Подробности Опубликовано: 14.07.2018 21:24 : рассматриваются базовые этапы внедрения корпоративных информационных систем. Кроме того выполняется обзор проектных документов каждого из этапов, а также демонстрируется зависимость данных заданной фазы на документы последующих этапов.
Скачать: PDF .
Ключевые слова: документы ERP систем, документирование внедрения корпоративных информационных систем, документирование информационных систем, документы в информационной системе, проектная документация ERP систем, рабочая документация ИС, техническая документация КИС, нормативные документы информационной системы, нормативные документы по проектированию информационных систем, документы внедрения ПО, документы внедрения информационных систем, этапы и документы внедрения программного продукта, опытная эксплуатация информационных систем, ГОСТ Р 54869-2011, ANSI PMBoK.

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

Цель и задачи

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

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

1. Обзор подходов внедрения корпоративных информационных систем

Корпоративная информационная система представляется совокупностью информационных систем (далее - ИС), определяющих заданную предметную область. Существует несколько подходов внедрения ИС, применимых так же для имплементации КИС (рис.1). Начнем обзор с подхода, декларированного государством. Речь идет об отраслевых стандартах, в частности, ГОСТ Р 54869-2011 , а так же международном стандарте ISO 21500 . Документы содержат описание этапов управления проектами от процесса инициализации до завершения вне зависимости от вида реализуемой системы. Поэтому возможно использование указанных стандартов для реализации технических, информационных и корпоративных систем. Свод профессиональных знаний по управлению проектами, представленный ANSI PMI PMBoK , регламентирует процессы планирования, исполнения, проверки и воздействия от этапа инициирования до завершения проекта. Аналогично ГОСТ Р 54869-2011 и ISO 21500 допускается его применение для управления внедрением различных видов систем.

Рис. 1.

Методологии Accelerated SAP (далее - ASAP) , Accenture Delivery Methods (далее - ADM) , а также Microsoft Dynamics Sure Step (далее - MDSS) используются компаниями SAP, Accenture и Microsoft соответственно при внедрении пакетированных КИС решений. Подходы ориентированы исключительно на реализацию проектов имплементации КИС. В рассмотренных выше подходах используется преимущественно каскадная схема внедрения КИС . Данная схема характеризуется строгой временной зависимостью выполнения этапов проекта. Работы на заданном этапе могут выполняться только в том случае, если реализованы все активности предыдущей фазы проекта. Наименование этапов разнится от подхода к подходу, однако, содержание работ неизменно. Поэтому вполне реально сформировать единый перечень как операций, так и подготавливаемых документов. Подытожим результат анализа подходов внедрения КИС списком типовых этапов реализации проекта (рис.2).

Рис. 2.

2. Проектные документы типовых этапов реализации проекта

В предыдущем разделе были выделены типовые этапы реализации проектов по внедрению КИС, включающие

• подготовку проекта;
• проектирование;
• реализацию;
• подготовку к опытно-промышленной эксплуатации (далее - ОПЭ);
• ОПЭ;
• переход к продуктивной эксплуатации (далее - ПЭ)

и являющиеся общими для методологий ASAP, ADM, MDSS и стандартов . Допускается отсутствие этапа ОПЭ, тогда 4-я и 5-я фазы проекта будут обеспечивать подготовку к ПЭ и ПЭ соответственно. Рассмотрим документы каждого из этапов подробнее (рис.3).

Рис. 3.

2.1. Этап подготовки проекта

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

2.2. Этап проектирования

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

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

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

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

2.3. Этап реализации

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

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

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

2.4. Этап подготовки к опытно-промышленной эксплуатации

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

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

2.5. Этап опытно-промышленной эксплуатации

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

2.6. Этап перехода к продуктивной эксплуатации

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

3. Зависимость подготавливаемых документов от этапов проекта

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

Рис. 4.

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

Результаты и выводы

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

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

Литература

1. ГОСТ Р 54869-2011. Проектный менеджмент. Требования к управлению проектом. – М.: Стандартинформ, 2011. – 10 с.
2. Zandhuis A., Stellingwerf R. ISO 21500. Guidance on Project Management. A pocket guide. – NL.: Van Haren Publishing, 2013. – 148 p.
3. ANSI/PMI 99-001-2014. A Guide to the Project Management Body of Knowledge (PMBOK Guide). – Pennsylvan.: Project Management Institute, 2013 – 589 p.
4. Brand H. SAP R/3 Implementation With ASAP: The Official SAP Guide. – NJ.: Sybex Inc, 1999. – 591 p.
5. Kress R. Running IT Like a Business: A Step-By-Step Guide to Accenture"s Internal IT. – Ely: IT Governance Publishing, 2012. – 140 p.
6. Shankar C., Bellefroid V. Microsoft Dynamics Sure Step 2010. – Birmingham: Packt Publishing, 2011. – 360 p.
7. Проектирование информационных систем: учебное пособие / Гвоздева Т.В., Баллод Б.А. – Ростов н/Д.: Феникс, 2009. – 508 с.
8. Ковалев С., Ковалев В. Секреты успешных предприятий: бизнес-процессы и организационная структура. – М.: БИТЕК, 2012. – 498 с.
9. Степанов Д.Ю. Обзор логистических бизнес-процессов на примере закупочной деятельности предприятия // Логистика сегодня. – 2014. – т.65, №5. – c.208-228.
10. Степанов Д.Ю. Формирование универсальных требований к пользовательским программам при подготовке спецификации на ABAP-разработку // Актуальные проблемы современной науки. – 2014. – т.78, №4. – c.258-268.

Планируем проект внедрения и доработки информационной системы в MS Project - быстро и красиво

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

Для того что бы не объяснять каждому новому ПМу как делать план в Project"e и какие работы и какую структуру туда закладывать, я решил сделать некий драфт плана, который показывал бы типовую структуру работ по проекту внедрения и доработки простой информационной системы, стоимостью приблизительно 5 миллионов рублей и сроком около полугода. Условно, заказчик хочет стартовать проект в мае, а завершить в октябре, при этом старт проекта для нас - начинается в апреле, с подготовки пилота и КП.

Описание проекта

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

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

Риски проекта

Поскольку никакого Rocket Science в проекте нет, его риски составляют около 10%. Заложить их можно по разному - добавить 10% к стоимости ресурсов (но это не учитывает сроки), планировать работы с учетом рисков накидывая 10% длительности к каждой сколько-либо рискованной (именно такой вариант использовал я), или сделать этап Contingency перед завершающим этапом (в моем случае он бы составлял 3 недели или ~1/10 от длительности проекта.

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

Команда проекта

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

• Ведущий разработчик - он же архитектор. Участвует в проработке архитектуры решения, оценке задач по разработке, обеспечивает наставничество команде разработки и помощь в решении сложных задач.
• Разработчик - основной разработчик проекта,
• Младший разработчик - джуниор на подхвате кода, решает задачи под контролем разработчика, параллельно учится.
• Аккаунт - менеджер по работе с клиентами, отвечает за взаимодействие с клиентом, составление и подписание договоров, контроль удовлетворенности клиента и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
• Куратор - высший менеджер компании исполнителя, обеспечивающий контроль и поддержку проекта. Может быть так же - руководитель портфеля проектов и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
• Заказчик - все сотрудники заказчика, привлекаемые к проекту. В плане - не детализируемы, предполагается что заказчик сам решит, кого из своих специалистов привлекать к тем или иным активностям.

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

Минимум миниморум:

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

Жизненный цикл проекта

В данном кейсе использован очень простой и распространённый жизненный цикл проекта - хорошо знакомый всем «Waterfall» где несколько фаз следуют друг за другом.

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

Так же для экономии места на экране я убрал отображение поля «Режим задачи» - на всех задачах он автоматический, ручного нигде нет.

Общий обзор этапов, их сроков и стоимости:

Итак, у нас есть 8 этапов (включая этап 0) и проект, который начинается 2 апреля, завершается 5 октября. Заказчику - можно вовсе не показывать этап 0, и конечно, не стоит его учитывать если вы не считаете ФОТ пресейлов и пилотов (но это для первый звоночек того, что вам есть над чем поработать, так как такой ФОТ считать нужно обязательно).

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

Этап 0 - подготовка проекта

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

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

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

При средних ставках внедренца и ПМа такой пилот будет стоить нам 59 400 рублей + еще 10800 рублей на его сопровождение, ведь у Заказчика появятся вопросы про его развертывание и использование. Ну как, вы все еще не хотите считать затраты на нулевом этапе?

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

Предположим, процесс описания скоупа и оценки у вас поставлен на поток, и после оценки куратор проекта одобряет ее (и накидывает % на торг и внепроектные риски) после чего КП отправляется на согласование заказчику. Здесь указанных 7 рабочих дней может быть явно мало, поэтому эта работа указана отдельно, и именно от нее зависит веха «КП Утверждено».

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

Этап 1 - сбор требований

Итак, вы успешно подписали контракт (или получили одобрение от спонсора внутреннего проекта) и теперь самое время стартовать, начав со сбора требований к системе. Но перед этим, надо надо устроить kick-off meeting, или как это называется на русском, стартовую встречу.

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

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

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

Рассмотрим несколько встреч на примере:

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

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

Естественно, это идеальный вариант, который работает только при наличии 2 очень сильных и мотивированных проектных команд.

В реальной жизни - отсидеть на встрече 4 часа и за 4 часа составить приличный протокол с описанием требований и договоренностей (или отревьювить его) - и так 6 дней подряд - довольно тяжело. Не говоря о том, что встреча может быть и более 4 часов (кстати, в этом случае эффективность встречи резко падает и протокол может быть и не согласован). Если сроки (и заказчик) позволяют - заложите 1 встречу в 2 дня, и возьмите запас недельку - для проведения дополнительных встреч и ревью протоколов. Если вы на 100% не уверены в заказчике и команде - никогда не ставьте на неделе более 3 встреч. Ну и конечно, все зависит от региона присутствия - если вы делаете проект в своем городе, или хотя бы в своей области - тут торопится смысла нет. Если же ваш заказчик из Нового Уренгоя, а вы - из Самары - увы, придется выложится на встречах по полной - мариновать команду без работы в другом городе нет никакого смысла. Так же, обязательно пропишите участие заказчика во встречах отдельной строкой - и вставьте это в договор.

Этап 2 - Архитектура и дизайн

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

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

Есть ли смысл детализировать эти 5 дней в задачи и отражать их в плане проекта? На мой взгляд нет, логичнее сделать это в Jira/Redmine, а заказчику/спонсору показать такой план.
У меня предусмотрено 2 итерации согласования - это совершенно разумно, но требует от заказчика определенной ответственности - на берегу стоит объяснить, что все замечания к ТЗ Заказчик выставляет в одной итерации, а во второй - только проверяет их исправление, а новые замечания - не ставятся. Если заказчик настаивает на третей итерации замечаний - что ж, хозяин барин, вставляем и третью (и четвертую, и пятую…) не забыв прописать затраты и объяснить заказчику насколько вырастет стоимость проекта. Презентовать ТЗ первый раз разумно вдвоем с аналитиком, а вот вычитывать его необходимо всей команде - на сколько либо больших проектах это весьма емкий документ, который является условием для завершения фазы проекта (а следовательно подписания актов и оплаты), и случайные ошибки в нем не допустимы. Если у вас в компании есть свободные ресурсы, например аналитики, логично подключить их к чтению ТЗ в качестве свежего взгляда - ТЗ от этого хуже не станет, а проект не подорожает на сколько бы существенно.

Этап 3 - Разработка

Итак, техническое задание подписано, и казалось бы можно приступать к разработке.
Первое, о чем хочется сказать - это предупредить о недопустимости начала разработки, без утвержденного ТЗ. Это ведет просто к тому, что одну и ту же работу приходится делать 2 раза. Конечно, если вы работает по Agile, и у вас четких требований нет, а есть заказчик платит по схеме Time&Materials, тогда смело игнорируйте это требование. Если же скоуп проекта у вас утвержден, оплата FixPrice и вы не закладывали бюджет и сроки на переделку задач, то не позволяйте разработчикам сделать ни единого коммита, без подписанного ТЗ.

Второе - конечно подразумевается, что инфраструктура для разработки развернута, а процессы отлажены. Нерадивые спонсоры и кураторы проектов, стремятся включить в бюджет проектов такие расходы - переход на использование CI, развертывание Jira/Redmine, переход на новую версию ПО и библиотек, БД и т.д. и т.п. Задача ПМа здесь - защитить свой проект (и его бюджет) от такого, аргументируя что такие вещи должны быть вынесены в отдельные проекты с отдельными бюджетами.

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

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

Этап 4 - Тестирование

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

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

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

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

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

Этап 5 - Внедрение

Ура! Мы добрались! Система на тестовых серверах работает как часы, команда QA отсыпается и уходит в отгулы, и пришел звездный час команды внедрения. Начинается он с развертывания окружения - и тут же у меня в плане заложен некий запас по времени, т.к. я подразумеваю что окружение развёртывали уже минимум 100 раз и в худшем случае на вашей корпоративной вике есть подробная инструкция по развертыванию, а в лучшем - внедренец сам ее писал. Главное, помните - после развертывания полезно протестировать все, что вы можете протестировать по заранее разработанному смоук-тесту, конечно же он остался у вас с фазы тестирования.
Теперь - о главном, ведь если дьявол и кроется где то, то это именно в интеграции и миграции данных. Сколько красивых диаграмм Ганта было погублено тем, что интеграция не была оттестирована тщательно и тем, что данные заказчика находились в ужасном состоянии, ненормализованные, выходящие за все грани разумного (и пределы полей), отличные от того, что написано в ТЗ.

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

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

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

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

Этап 6 - Поддержка

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

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

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

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

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

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

Стратегия построения информационной системы

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

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

· Разработка собственной специализированной системы или настройка существующих систем.

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

· Интеграция существующих подсистем по функциям и по данным.

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

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

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

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

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

· только планирование или планирование и контроль хода проекта;

· планирование и контроль лишь сроков выполнения работ;

· планирование и контроль финансовых вложений без детального планирования использования ресурсов;

· детальное планирование использования ресурсов;

· многопроектное планирование и управление.

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

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

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

Разработка информационной системы

Можно выделить три основных стадии разработки информационной системы управления:

· Изучение и анализ возможностей автоматизации процедур управления;

· Проектирование и разработка системы;

· Тестирование и подготовка документации.

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

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

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

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

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

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

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

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

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

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

Внедрение системы

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

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

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

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

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

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

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

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

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

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

Литература

[I]. Л Guide to the Project Management Body of Knowledge (PMBOK), PMI, 1994.

. Andersen E, Grude K, Haug T, Turner J, Goal Directed Project Management, Kogan Page, 1995.

. Morris P, Managing Project Interfaces - Key Points for Project Success, Project Management Handbook, edited by D. Cleland and W. King, Van Nostrand Reinhold, 1988.

. Meredith J., Mantel S., Project Management, Managerial Approach, Wiley, 1989.

. The Implementation of Project Management: The Professional Handbook, Wesley, 1991.

[б]. Полковникова Е.В., Полковников А.В., Планирование и управление проектами с использованием Time Line, Диалог-МИФИ, 1994.

. Thuman J, Development and Implementation of Project Management Systems, Project Management Handbook, edited by D. Cleland and W. King, Van Nostrand Reinhold, 1988.

. Badiru A, Whitehouse G, Computer Tools, Models and Techniques for Project Management, TAB Professional and Reference Books, 1989.

. Levine H A, Project Management Using Microcomputers, McGraw Hill, 1986.

. Wall A, Project Planning and Control Using Micros, NCC Publications, 1988.

SQL (Structured Query Language) - стандартный, структурированный язык построения запросов к базам данных.

ODBC (Open Data Base Connectivity) - стандарт доступа к базам данных различных форматов.

Web - всемирная сеть, построенная по технологии Internet.

ASCII - формат сруктурированного текстового файла.

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

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

К настоящему времени сложился стандартный набор приемов внедрения ИС. Основное правило: выполнять обязательные фазы последовательно и не пропускать ни одной из них .

Критически важными для внедрения являются следующие факторы :

· наличие четко сформулированных целей проекта и требований к ИС;

· наличие стратегии внедрения и использования ИС;

· проведение предпроектного обследования предприятия и построения моделей "Как есть" и "Как будет";

· планирование работ, ресурсов и контроль выполнения плана внедрения;

· участие высшего руководства во внедрении системы;

· проведение работ по внедрению ИС специалистами по интегрированию систем совместно со специалистами предприятия;

· регулярный мониторинг качества выполняемых работ;

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

Перед началом разработки проекта внедрения необходимо:

· максимально формализовать цели проекта внедрения ИС;

· оценить минимально необходимые затраты и статьи расхода;

· установить высокий приоритет проекта внедрения перед остальными текущими проектами;

· наделить руководителя проекта максимально возможными полномочиями;

· провести массовую просветительскую работу с персоналом предприятия с целью довести до каждого важность и необходимость предстоящих преобразований;

· разработать организационные меры для применения новых информационных технологий;

· распределить персональную ответственность по всем этапам внедрения и опытной эксплуатации.

Необходимо также определить функциональные сферы внедрения модулей информационной системы:

· организационное управление;

· организационно-административное обеспечение;

· управление бизнес-процессами;

· управленческий, планово-финансовый и бухгалтерский учет;

· управление персоналом;

· управление документацией;

· управление материально-техническим обеспечением;

· управление связями с клиентами и внешней средой.

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

· системная платформа - внедрение и адаптация готового решения от производителя или разработка на заказ в соответствии с техническим заданием заказчика;

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

· адаптируемость - система настраивается в соответствии с требованиями заказчика и на особенности информационного поля заказчика;

· распределенность - система может эффективно функционировать в территориально удаленных подразделениях и филиалах предприятия;

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

6.6.1 Основные фазы внедрения информационной системы

Фаза "Предварительные работы по подготовке проекта внедрения ИС" . В ходе предпроектного обследования предприятия (рис. 4) происходит сбор подробной информации о структурном построении организации, функциональных связях, системе управления, об основных бизнес-процессах, о потоках внутри предприятия (Control Flow, Doc Flow, Data Flow, Work Flow, Cash Flow), необходимой для построения соответствующих моделей и выбора объектов для автоматизации. Оцениваются сроки, ресурсы, виды и объемы работ, номенклатура и стоимость программно-аппаратных и телекоммуникационных средств, стоимость обучения персонала и т. д.

Фаза "Подготовка проекта" . После завершения первой фазы осуществляется предварительное планирование и формирование процедур запуска проекта:

· формирование проектной и экспертной групп;

· распределение полномочий и ответственности;

· определение организационно-технических требований к процессу внедрения;

· уточнение спецификаций и ожиданий заказчика;

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

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

Фаза "Концептуальная проработка проекта" . В течение этой фазы:

· формируется и утверждается концептуальный проект;

· уточняются и конкретизируются цели и задачи проекта;

· определяются размеры прототипа системы;

· согласуются укрупненный план работы, последовательность этапов и условия опытной эксплуатации, планово-финансовые и отчетные показатели;

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

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

Рисунок 12 - Примерное содержание репозитория проекта внедрения

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

Рисунок 13 - Примерный состав документации по процессу внедрения информационной системы

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

После окончания фазы реализации проект внедрения считается законченным. Информационная система передается в эксплуатацию.

Контрольные вопросы

1. Что такое "открытая информационная система"? Перечислите основные свойства открытых систем.

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

3. Какие модели и каким образом используются при проектировании информационных систем?

4. Какие программные средства используются для моделирования процессов при разработке информационных систем?

5. На основании каких данных и информации разрабатываются модели состояния AS IS и AS TO BE?

6. Кто в компании занимается вопросами разработки, внедрения и развития ИС? Кто участвует в подготовке технического задания на разработку ИС?

7. Назовите основные этапы проектирования информационных технологий.

8. Перечислите этапы жизненного цикла информационной системы.

9. На каком этапе разработки и внедрения ИС производится обучение персонала компании?

10. Перечислите основные фазы внедрения ИС.