33. Недостатки erp-систем

Неэффективность внедрения.

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

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

Сложность эффективной интеграции с внешними приложениями.

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

Низкая производительность.

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

Ограниченные аналитические возможности.

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

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

В большинстве ERP-систем реализованы возможности получения только статичных (хотя и комплексных) отчетов. Существующие генераторы отчетов имеют весьма ограниченные возможности "погружения" вглубь данных по вертикали и совершенно не позволяют перемещаться между данными по горизонтали. Комплексные массивы структур данных в ERP-системах заставляют создавать комплексные запросы на генерацию отчетов. Кроме того, отчеты разрабатываются отдельно для каждого случая, поэтому их приходится готовить заново при любом изменении бизнес-процессов. Вследствие этого, на мировом рынке присутствует большое количество генераторов отчетов разработки третьих фирм, непосредственно обращающихся к базам данных распространенных ERP-систем. Например, фирма Seagate Software с помощью генератора отчетов Crystal Reports предоставляет распределенную отчетность пользователям ERP-системы PeopleSoft, компания Quest Software поставляет ПО Quest Output Management Suite, обеспечивающее Web-доступ к отчетам и документам, хранящимся в ERP-системе, управление ими и последующее распределение их по корпоративной сети.

34	Методология внедрения ERP-систем

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

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

Техника подготовки и проведения основных фаз внедрения будет интересна всем, кто собирается произвести замену унаследованных систем на системы класса ERP

Методология внедрения ERP-системы

Этап 1. Предпроектная подготовка

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

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

Этап 2. Официальное открытие проекта

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

35	Свод знаний по управлению проектами (PMBOK): управление интеграцией проекта.

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

На рис. 4-1 представлена общая схема следующих процессов управления интеграцией проекта:

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

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

4.3 Руководство и управление исполнением проекта – процесс исполнения работ, определенных в плане управления проектом, для достижения целей проекта.

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

4.5 Осуществление общего управления изменениями – процесс проверки всех запросов на изменение, их утверждения и управления изменениями результатов, активов процессов организации, документов проекта и плана управления проектом.

4.6 Завершение проекта или фазы – процесс завершения всех операций всех групп процессов управления проектом с целью формального завершения проекта или фазы.

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

36.	Свод знаний по управлению проектами (PMBOK): управление сроками проекта.

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

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

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

6.3 Оценка ресурсов операций – процесс оценки типов и количества материалов, человеческих ресурсов, оборудования или поставок, необходимых для выполнения каждой операции.

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

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

6.6 Управление расписанием – процесс мониторинга статуса проекта для корректировки его исполнения и внесения изменений в базовое расписание.

Управление расписанием связано с:

• определением текущего состояния расписания проекта;

• влиянием на факторы, вызывающие изменения расписания;

• определением фактов изменения расписания проекта;

• управлением фактическими изменениями по мере их возникновения.

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

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

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

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

37.	Свод знаний по управлению проектами (PMBOK): управление стоимостью проекта.

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

7.1 Оценка стоимости – процесс определения примерной стоимости ресурсов, необходимых для выполнения операций проекта.

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

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

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

Бюджеты проекта представляют собой денежные средства, санкционированные для выполнения проекта. Выполнение стоимости проекта сравнивается с санкционированным бюджетом.

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

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

Управление стоимостью проекта включает в себя:

• влияние на факторы, вызывающие изменения санкционированного базового плана по стоимости;

• обеспечение своевременной обработки всех запросов на изменение;

• управление фактическими изменениями по мере их возникновения;

• обеспечение расходования средств в рамках утвержденного бюджета в течение определенного периода или на протяжении всего проекта;

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

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

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

• информирование соответствующих заинтересованных сторон проекта обо всех одобренных изменениях и связанной с ними стоимости; и

• действия по сокращению ожидаемого перерасхода средств до приемлемого уровня.

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

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

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

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

38. Свод знаний по управлению проектами (PMBOK): управление качеством проекта.

PMBOK (Project Management Body of Knowledge) - это общепризнанный свод знаний по управлению проектами, который разработан и поддерживается организацией PMI.

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

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

На рис. 8-1 представлена общая блок-схема процессов управления качеством проекта, которые включают в себя следующее:

8.1 Планирование качества – процесс определения требований и/или стандартов качества для проекта и продукта, а также документирования того, каким образом проект будет демонстрировать соответствие установленным требованиям и стандартам

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

8.3 Контроль качества – процесс контроля и записи результатов выполнения действий по обеспечению качества для оценки исполнения и разработки рекомендаций относительно необходимых изменений.

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

38. Свод знаний по управлению проектами (PMBOK): управление человеческими ресурсами проекта.

PMBOK (Project Management Body of Knowledge) - это общепризнанный свод знаний по управлению проектами, который разработан и поддерживается организацией PMI.

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

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

На рис. 9-1 приведена общая схема следующих процессов управления человеческими ресурсами проекта:

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

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

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

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

38. Свод знаний по управлению проектами (PMBOK): управление коммуникациями проекта.

PMBOK (Project Management Body of Knowledge) - это общепризнанный свод знаний по управлению проектами, который разработан и поддерживается организацией PMI.

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

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

На рис. 10-1 представлена общая схема процессов управления коммуникациями проекта, которые включают в себя следующее:

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

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

10.3 Распространение информации — процесс предоставления значимой информации заинтересованным сторонам проекта в соответствии с планом.

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

10.5 Отчеты об исполнении — процесс сбора и распространения информации об исполнении, включая отчеты о текущем состоянии, оценку исполнения и прогнозы.