Книги по разным темам Pages:     | 1 |   ...   | 3 | 4 | 5 | 6 | 7 |   ...   | 10 |

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

Разработка предметной области проекта Ч документальное представление и подтверждение предметной области, которые включают:

Х обоснование проекта Х основные цели и задачи проекта;

Х критерии и оценки успеха проекта или его частей.

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

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

Анализ требований - это первая стадия планирования предметной области проекта.

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

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

Х Технический Х Финансовый Х Коммерческий Х Организационный Х Социальный Х Экономический Взвесив все за и против проекта, необходимо приступать к формулировке требований. На этом этапе необходимо определиться с вопросом Что должна делать будущая система.

Список требований к КИС должен включать:

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

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

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

Описание требований.

первоначально необходимо формализовать требования, предъявляемые на первом этапе внедрения. То есть необходимо подготовить документ, в котором будет строго и четко сформулированы требования к системе, а также, что немаловажно, форма их выполнения в конкретной системе. Степень детализации такого документа очень высока. В реальной проектной документации зачастую можно увидеть требования/описания к конкретному окну или строке. То есть, если заказчик желает, чтобы новые, необслуженные заказы были на виду, то в описаниях требования необходимо указать, что в модуле ЗАКАЗЫ, в таблице ЗАКАЗАНО сортировка должна быть по выполнению, а невыполненные заказы должны выделяться красным цветом (пример из проектной документации Columbus IT partners) Анализ процессов, документирование решения.

Анализ бизнес процессов является ключевой стадией внедрения ERP системы.

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

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

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

Схема составлена на основании личного опыта анализа бизнес процессов управления заказами.

Управление проектами по внедрению КИС Формирование заказа Создание нового Заказы/заказ, шапка нового заказа Начало заказа Получение Заказы/заказ, новый заказ с Создание строк заказа информации финансовой и складской аналитикой по товарам и услугам о заказе Нужно Выставление регистрировать нет счета на договор предоплату Нужно корректировать резервирование Да Коррекция Закупки/закупка товаров и резервирования Изменение строки закупки услуг товаров и услуг Счет на нет предоплату Нужно изменить да условия заказ Изменение строк заказ Клиент Закупки/закупка нет Изменение строки закупки да Заказы/заказы Проводка накладной проверка осуществимости отпуска со склада Все количество товара проведено по накладной Анализ взаимо- Заказы/заказы отношений с Проводка счета проведен счет факура, осуществлен клиентом фактуры физический и экономический расход товара Все количество Конец товара проведено счету-фактуре Регистрация договра с клиентом Регистрация платежа от клиента Менеджер по заказм Бухгалтер Юрист Управление проектами по внедрению КИС Техническая инфраструктура На основе дизайна решения формируются требования к технической части системы. Документ по технической инфраструктуре должен включать:

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

Дизайн проекта Это заключительная стадия проектирования предметной области ERP системы.

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

Детализация проекта и конкретных задач.

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

Наиболее эффективным методом такого деления проекта является создание иерархической структуры проекта (ИСП), также часто называемой иерархической структурой работ (ИСР) [PMI: Work Breakdown Structure] или структурной декомпозицией работ (СДР) [1].

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

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

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

Использование ИСП.

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

Ниже приводится типичная процедура работы с ИСП [10]:

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

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

Х определяются пакеты работ (задачи), по которым необходимо подготовить планы, оценки, бюджеты, календарные планы и выполнение которых должно контролироваться;

Х для каждого элемента структуры проекта ("сверху вниз" - на всех уровнях до каждой задачи) указываются:

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

o спецификации продукта o основной контракт, контракты с субподрядчиками и основные заказы o оценки и бюджеты ресурсов (сотрудники, фонды, программное и аппаратное обеспечение) и бюджеты;

o номера рабочих заданий/нарядов на работы;

o номера счетов издержек (только на уровне задач);

o контрольные события и относящиеся к ним операции в сетевых планах: методика анализа и оценки проекта или программы (PERT)/метод критического пути (СРМ)/управление данными о продукте (PDM) с запланированными датами;

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

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

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

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

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

При разработке ИСП необходимо принимать во внимание следующие основные правила:

Х Каждый элемент ИСП должен обеспечивать достижение ощутимого результата.

Х Каждый элемент ИСП должен являться агрегатом всех подчиненных элементов, перечисленных непосредственно под ним.

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

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

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

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

Х Все результаты в явном виде должны быть включены в ИСП.

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

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

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

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

Pages:     | 1 |   ...   | 3 | 4 | 5 | 6 | 7 |   ...   | 10 |    Книги по разным темам