Комментарии 8
Ворос: "ERP-проекты: как не стать частью провалов".
Ответ: "На начальной стадии проекта необходимо реализовать MVP".
Проблема решена.
То, что "внедрение ERP" - это такой вид бизнеса консультантов, который не предполагает завершения внедрения (есть разные сказки про "непрерывное развитие бизнеса", "изменчивость среды" (надо не забыть тут где раз 10 упомянуть "вэлью")) - мы же не рассматриваем?
И то, что "внедрение ERP" - это скорее про настройку процессов под софт или потребности бизнеса, а уж софт там на самом деле вторичен - мы ж не будем говорить?
По факту первым шагом "ERP-проекты: как не стать частью провалов" для команды исполнителя надо для себя честно сказать "что мы хотим" (освоить бюджет, получить "дойную корову на многие годы", или, не дай бог, всё-таки внедрить ERP (вы точно что-то хотите?)). И точно также команде (собственнику?) заказчика понять, на что они готовы пойти и зачем им на самом деле ERP ("модно", "надо на продажу", что-то ещё"). И честно договориьтся между собой (кто-нибудь верит, что это возможно? :))
PS. Про модульное внедрение - финансовый блок и кадры - и вот наш "успешный успех"??? Или нет?
Дебетовая разве не пакетом грузится? Что там списывать то? Да и сомневаюсь что хоть какой-то в здравом уме руководитель спишется дебиторку, где х ≠ 0
Имею успешный опыт внедрения SAP SuccessFactors в трех международных компаниях масштаба 60к сотрудников. Часто делюсь этим опытом на канале Морковка спереди морковка сзади у Пети Жаркова.
Хочу заметить, что в моей практике совершенно не важна орг структура проекта, в большинстве случаев получалась плоская - все со всеми и над этим управляющий комитет.
Важна реальная заинтересованность спонсора в результатах проекта. Важна власть принимающего решение и его дистанция до проекта. Важен процесс делегирования через полномочия, влияние, власть и ответственность.
Когда РП пытаются делегировать только через ответственность не оставляя ни прямой власти, ни «ручейка наверх»
Когда сам РП имеет низкое влияние и не может его развить в первой трети проекта оперевшись на свои полномочия, опыт, харизму, стратегическое видение…
Когда лица принимающие решения отдаляются от управления и РП проваливается в дефицит власти, вот тогда и начинается беспомощность.
Главный инструмент РП тут - манипуляция правом на незнание:
«Решение списать всю дебиторскую задолженность менее Х руб или не списать не принято. Желаемая дата: х.х.х.х если не сделано то…»
Когда на стирко второй раз появляется такая формулировка и спонсор заинтересован в результате - решение немедленно принимается, а те кто не подготовил его и не высказал позицию на стирко: «перед нами стоит сложный выбор бла бла бла, и мы (менеджеры высшего звена, фин директор в том числе) считаем, что… вот тот мгновенно оказывается в позиции виноватого.
И это не РП.
РП лишь обязан лишить всех «мы» права на незнание что такой вопрос открыт за разумный срок до заседания стирко, ловко манипулируя тем кому о важности этого решения можно не знать, а кому положено.
Из недооцененных очевидных задач ещё как минимум НСИ, миграция, разработка или адаптация методологий и интеграция.
Из факторов провалов вообще не сказано про плохой или отсутствующий change management.
Статья хорошая, но основной упор сделан на полномочиях РП и короткой цепочке принятия решений. Это тормозит проекты, безусловно, но больше характерно для небольших и средних проектов.
Для крупных начинается другая история - ЛПР слабо представляют что творится "внизу" со всеми отсюда вытекающими последствиями. И тут как раз нужен change management, который поможет снять часть рисков.
Долго можно продолжать. По сути по каждой типовой проблеме можно написать статью, и не одну.
Конечно, факторов провала множество(этим и хороша дисциплина Управления проектами- нет предела куда развиваться). Change management безусловно важная тема. Цель статьи была выделить ключевые факторы(на основании моего опыта). Если вы хотите родить за 6 месяцев, никакой change management не поможет). И если нет четкой вертикали управления, то не вовлеченный менеджмент "напихает" своих хотелок в проект.
И конечно согласен, что по каждой проблеме невинно статью писать.

ERP-проекты: как не стать частью провалов