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

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

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

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

Программа реализуется с 2012 года.

За это время прошли обучение несколько сотен человек из Владивостока, Екатеринбурга, Тулы, Самары, Воронежа, Сочи, Новгорода, Читы, Москвы и других городов.

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

Руководитель проектов в области информационных технологий (Утвержден Приказом Минтруда России №893н от 18.11.2014)
Системный аналитик (Утвержден Приказом Минтруда России № 809н от 28.10.2014)

Форма обучения:	заочная (дистанционная)
Срок обучения по программе:	8 месяцев
Выдаваемый документ:	диплом установленного образца Высшей школы экономики о профессиональной переподготовке. Диплом дает право на ведение профессиональной деятельности в сфере управления информационными технологиями
Начало занятий:	05 июня 2019 года Прием документов до 25 мая 2019 года
Условия поступления:	Лица, имеющие среднее профессиональное или высшее образование; - лица, получающие профильное (техническое, экономическое, управленческое) высшее образование.
Стоимость	136 000 рублей. Оплата производится частями. Минимальный платеж - 1 раз за 2 месяца.

Подайте заявку на обучение

ЦЕЛИ ПРОГРАММЫ

Дать слушателям необходимые теоретические знания в области системного анализа и ИТ-менеджмента;

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

Изучить практику управления ИТ-проектами в российских компаниях и организациях;

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

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

Структура и содержание программы

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

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

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

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

1. Анализ предметной области и формирование требований к ИС

Информатизация предприятия
Анализ требований к автоматизированным информационным системам
Архитектура предприятия
Моделирование бизнес-процессов
Оптимизация бизнес-процессов
Контрольное домашнее задание 1.

2. Разработка и проектирование ИС

Модели жизненного цикла и методологии разработки корпоративных систем
Технологии и средства разработки корпоративных систем
Проектирование информационных систем
Применение ГОСТ 34 в проектах создания современных автоматизированных систем
Основы проектирования реляционных баз данных
SQL и процедурно-ориентированные языки
Контрольное домашнее задание 2

3. Внедрение ИС

ИТ-стратегия
Управление внедрением информационных систем
Гибкая процессная методология Agile
Управление проектами в соответствии со стандартом PMI PMBOK
Управление проектами по технологии быстрого результата
Контрольное домашнее задание 3.

4. ВЫПУСКНАЯ АТТЕСТАЦИОННАЯ РАБОТА

Особенности заочного (дистанционного) обучения

Материалы дисциплин представлены в виде видеофильмов или электронного текста.

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

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

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

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

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Подобные документы

Особенности проектирования информационных систем основанных на базах данных. Использование CASE-средств и описание бизнес процессов в BP-Win. Этапы проектирования современных информационных систем, виды диаграмм и визуальное представление web-сайта.

курсовая работа , добавлен 25.04.2012

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

дипломная работа , добавлен 20.07.2014

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

курсовая работа , добавлен 14.11.2017

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

презентация , добавлен 07.04.2013

Обзор принципов построения и эффективного применения систем управления базами данных, CASE-средств автоматизации проектирования. Анализ возможностей методологии и инструментальных средств. Разработка модели бизнес-процессов гостиницы в среде All Fusion.

курсовая работа , добавлен 28.12.2012

Наличие экономической информационной системы. Матрица организационных проекций. Разработка системы базы данных. Современные CASE-средства. Основные этапы разработки информационных систем. Абсолютный показатель и индекс снижения стоимостных затрат.

курсовая работа , добавлен 14.03.2011

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

курсовая работа , добавлен 07.04.2015

Роль инструментальных средств проектирования в создании информационной системы. Преимущества CASE-средств разработки Bpwin и Erwin, системы поиска, исправления ошибок модели данных Model Validator. Разработка модели процессов документооборота предприятия.

контрольная работа , добавлен 24.06.2012

Планируем проект внедрения и доработки информационной системы в 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 в месте, где его можно будет легко и безопасно забрать.

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

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

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

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

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

Технологические элементы, обеспечивающие функционирование системы:

Информационную модель предметной области;

Кадровые ресурсы, отвечающие за формирование и развитие информационной модели;

Программный комплекс;

Кадровые ресурсы, отвечающие за конфигурирование программного комплекса;

Аппаратно-техническую базу;

Эксплуатационно-технические кадровые ресурсы;

Управленческие элементы, обеспечивающие организацию эксплуатации системы:

Регламент развития информационной модели и правила внесения в нее изменений;

Регламент технической и пользовательской поддержки программного комплекса;

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

Регламент использования программного комплекса и пользовательские инструкции;

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

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

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

Отсутствие постановки менеджмента на предприятии;

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

Необходимость изменения технологии бизнеса в различных аспектах;

Сопротивление сотрудников предприятия;

Временное увеличение нагрузки на сотрудников во время внедрения системы;

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

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

Значительная часть проблем проектов внедрения обусловлена довольно типичными ошибками, которые известны, но тем не менее часто повторяются:

Проектирование систем без учета стратегии развития бизнеса - необходимо представлять структуру и масштабы бизнеса в перспективе как минимум на 3 года;

Нарушение принципа построения системы "сверху-вниз" и, как следствие, отсутствие информационной поддержки принятия управленческих решений на верхних уровнях управления;

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

Кардинальная переработка базовой функциональности ERP-системы;

Нереалистичные ожидания вследствие неверной оценки экономической эффективности внедрения ERP-системы.

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

Факторы успеха проекта внедрения

Тетодологии внедрения обычно разрабатываются ведущими производителями информационных систем с учетом особенностей их программных продуктов, а также сферы внедрения. Положительная сторона таких стандартов - их практическая направленность. Они представляют собой глубоко проработанные, проверенные, многократно апробированные рабочие инструкции и шаблоны проектных документов. Такие стандарты обычно далеки от теоретических абстракций, ориентированы на особенности конкретных систем, содержат наилучший опыт. Но у стандартов есть и отрицательные стороны: даже методологии, предназначенные для систем, близких по классу, не взаимозаменяемы. Например, методология внедрения системы Microsoft Axapta направлена во многом на управление настройками модулей и доработками; а при внедрении функционально подобных модулей SAP или ORACLE EBS превалирует идеология бизнес-реинжиниринга, при котором организации предлагается изменять свои бизнес-процессы, адаптируя их под "лучший опыт", зафиксированный в системе. В качестве наиболее известных примеров методологий можно привести следующий, далеко не исчерпывающий перечень:

Разработки компании Microsoft - методологии "OnTarget", "MSF (Microsoft Solutions Framework)", "Business Solutions Partner Methodology";

Разработки компании SAP - методологии "Процедурная модель SAP", "ASAP (Accelerated SAP)";

Разработки компании Oracle - комплекс методологий "Oracle Method".

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

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

Создание решения, оптимально соответствующего требованиям клиента;

Максимально эффективное использование ресурсов проекта;

Минимизация сроков и затрат на внедрение;

Уменьшение рисков проекта.

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

Появляется методическая база для обучения новых сотрудников стандартным методам внедрения;

Сокращаются внутренние расходы на организацию и реализацию проектов;

Улучшается взаимодействие и взаимопонимание между членами проектной группы;

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

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

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

Данные проектной документации не устаревают;

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

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

Оптимизируются бюджет проекта и график платежей.

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

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

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

Составляющие методологии внедрения

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

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

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

2. Построение информационно_функциональной модели деятельности предприятия (IDEF), описание и оптимизация процессов, подвергающихся автоматизации.

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

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

3. Выполнение пилотного проекта.

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

4. Адаптация системы на предприятии.

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

5. Опытная эксплуатация ERP_системы.

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

6. Ввод системы в промышленную эксплуатацию.

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

7. Сопровождение промышленной эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Литература

[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 - формат сруктурированного текстового файла.