Вкратце

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

Как незначительные запросы на внесение изменений в ERP-систему приводят к расширению объема работ

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

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

Последствия изменений в сфере применения системы ERP для операционной деятельности и тестирования на последующих этапах

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

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

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

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

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

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

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

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

Основные показатели расширения объема работ в проектах ERP

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

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

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

Система принятия решений спонсором по запросам на внесение изменений в систему ERP

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

Вариант 1: Утвердить и профинансировать расширение объема работ по внедрению ERP-системы

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

Вариант 2: Перенести запросы по ERP на релизы, выпущенные после запуска системы

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

Вариант 3: Изменение объема работ по внедрению ERP-системы для обеспечения соблюдения сроков запуска

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

Вариант 4: Отклонять запросы на внесение несущественных изменений в систему ERP

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

Орган, уполномоченный утверждать изменения в сфере ERP

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

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

Триггеры эскалации для спонсоров в случае изменений бюджета и графика в системе ERP

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

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

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

Роли по утверждению трансграничных операций для заводов и головного офиса группы

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

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

Обязательные поля записи о решении по внедрению ERP-системы

В журнале учета решений об изменениях на каждого заявителя отводится одна страница. Это рабочий инструмент для контроля изменений в сфере ERP. CE Interim предлагает его в качестве практического пособия, а не в качестве официально признанного стандарта. Журнал состоит из шести полей.

• Описание запроса на изменение: что просит заявитель и почему именно сейчас.
• Бизнес-ценность и операционное обоснование: процесс, который он защищает.
• Затраты поставщика и влияние на внутренние ресурсы: внешняя плата, затраты внутреннего персонала и остаток резерва на непредвиденные расходы до и после.
• Анализ зависимости тестирования и влияния графика: тесты и даты, на которые это влияет.
• Изменение области применения или замена: что, если что-то и останется, выйдет из выпуска.
• Утверждённое решение и обновлённая исходная база: лицо, утвердившее решение, выбранный вариант и пересмотренный план.

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

Контрольный список для проверки спонсора перед утверждением изменений в объеме проекта ERP

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

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

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

Примеры из практики: оценка изменений в объеме внедрения ERP на основе фактических данных

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

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

Пример применения: автоматизированное оформление возврата на линии

Завод хочет, чтобы операторы перестали вводить данные о возврате лома вручную, и эта просьба соответствует базовым требованиям.

• Запрос: Автоматическое оформление возврата груза на линии.
• Преимущество: устраняет необходимость ручного ввода данных о возврате брака; экономит 1,5 административных часа за смену.
• Стоимость: 18 500 евро — оплата услуг внешнего подрядчика; 45 часов — время, затраченное внутренними ключевыми пользователями на настройку.
• Тестирование и график: Требуется 4 дня регрессионного тестирования в рабочей группе «Сборка»; задержка по критическому пути отсутствует.
• Выход за рамки: не требуется; непредвиденные обстоятельства учтены.
• Решение и исходные данные: Утверждено («Принять сейчас»): обновлен базовый бюджет; тестирование завершено в 4-м спринте.

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

Пример обмена данными Scope: настраиваемая панель показателей KPI для руководства

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

• Запрос: Индивидуальная панель показателей KPI для руководства.
• Значение: Заменяет статическую отчетность в формате электронных таблиц для исполнительного руководства группы.
• Стоимость: 34 000 евро на разработку со стороны поставщика; 30 часов на проверку отчетности центрального финансового отдела.
• Тестирование и график: высокая сложность; отвлекает основных архитекторов системы отчетности на период проведения приемочных испытаний.
• Изменение области применения: перенести составление некритичных сводных отчетов по центрам затрат на второй день.
• Решение и исходные данные: Обсуждение объёма работ: одобрено к первоначальному выпуску; подготовка сводных отчётов отложена до этапа 1.1.

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

Пример отсрочки: отслеживание поддонов по конкретному клиенту

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

• Запрос: отслеживание поддонов по конкретному заказчику.
• Значение: Выполнение нестандартного логистического запроса для одного регионального дистрибьютора.
• Стоимость: комиссия продавца в размере 26 000 евро; обширная индивидуально разработанная логика в модуле управления складом.
• Тестирование и график: задержка утверждения интеграции системы управления складом на 12 рабочих дней.
• Объем работ, выходящий за рамки проекта: Запрашивающим рабочим потоком не выявлено.
• Решение и исходные условия: Перенесено на этап 1.1: развернуто через 60 дней после запуска; вначале использовался журнал ручной упаковки.

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

Пример отказа: автоматизированное выставление счетов поставщиками по системе самовыставления счетов

Финансовый отдел стремится ускорить сопоставление счетов-фактур по всей цепочке поставок, и преимущества этого вполне очевидны.

• Запрос: Автоматизированное выставление счетов поставщиками.
• Значение: Ускоряет сопоставление счетов-фактур по кредиторской задолженности в рамках европейской базы поставщиков.
• Стоимость: 52 000 евро на разработку со стороны поставщика; значительная перенастройка интерфейса EDI.
• Тестирование и график: Вносит изменения в основные правила проводки финансовых данных; ставит под угрозу сроки перехода на новую финансовую систему.
• Смещение области действия: Нет; запрашивающая команда не готова изменить объем работ.
• Решение и исходные условия: Отклонено: высокий риск, связанный с графиком; для запуска системы сохраняется стандартная процедура сопоставления заказов на закупку.

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

Основные выводы из примеров изменения объема работ по внедрению ERP-системы

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

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

Устранение пробелов в управлении при контроле изменений в сфере ERP

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

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

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

Роль временного директора по трансформации в управлении ERP-системой

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

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

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

Определение временного мандата по надзору за исполнительной властью

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

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

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

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

Опубликованы рекомендации по управлению сферой применения ERP-систем

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

Поставщик услуг в области ERP-систем «Atreus» сообщает о задержка внедрения системы ERP в сфере послепродажного обслуживания что ситуация стабилизировалась. Были пересмотрены объем работ, бюджет и этапы реализации, а также определены роли и сфера ответственности бизнес-подразделений, ИТ-отдела и партнёров. Ни один из источников не описывает этот отчёт и не выделяет какое-либо одно изменение в качестве причины. Отчёт «Atreus» представляет собой отчёт поставщика, а не результаты независимого аудита.

Часто задаваемые вопросы об управлении изменениями в сфере ERP

Следует ли заморозить изменения в объеме внедрения ERP-системы незадолго до запуска?

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

Кто утверждает изменения в рамках системы контроля изменений в ERP?

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

Заменяет ли временный руководитель директора программы ERP?

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

Что происходит с согласованной датой запуска после утверждения изменений в системе ERP?

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

Связанные знания и дальнейшие действия

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

Рекомендуемые материалы:

• Закрытие завода в США из Германии: временный руководитель предприятия, который справился с этой задачей за шесть месяцев
• Один поставщик обслуживает несколько заводов в странах Центральной и Восточной Европы. Как следует распределять ограниченные запасы материалов?
• Почему установка целевого показателя себестоимости продукции не является переработкой операционной модели

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

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