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

[mazzy]

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

Подробнее...
http://axapta.mazzy.ru/lib/unsuccess/

[Dzemon]

Довольно поверхностно. Мало уделено внимания "человеческому фактору".

[mazzy]

Цитата:

Сообщение от Dzemon

Довольно поверхностно. Мало уделено внимания "человеческому фактору".

Что бы ты добавил (посоветовал добавить)?

[Dzemon]

Да много уже чего писали по этому поводу.
Особо хочется отметить мотивацию сотрудников, особенно среднего слоя менеджмента и отдела ИТ.

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

[Sitizen]

Собственно ничего нового.
Я бы сократил статью до нескольких предложений.
Факторы неуспешности:
1. Неэффективное управление проектом (под управлением понимается управление временем, изменениями, придметом, рисками, бюджетом, ожиданиями)
На мой взгляд все перечисленные факторы попадают по этот.

Минимизация метрики неуспешности:
1. Увеличение бюджета проекта

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

[mazzy]

Цитата:

Сообщение от Sitizen

Таки образом упрощаем статью до трех предложений:

Как-то уж очень... всю религию к непотребству свел...

[Sitizen]

Цитата:

Сообщение от mazzy

Цитата:

Сообщение от Sitizen

Таки образом упрощаем статью до трех предложений:

Как-то уж очень... всю религию к непотребству свел...

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

[vaavr]

Цитата:

Сообщение от Sitizen

Собственно ничего нового.
Я бы сократил статью до нескольких предложений.
Факторы неуспешности:
1. Неэффективное управление проектом (под управлением понимается управление временем, изменениями, придметом, рисками, бюджетом, ожиданиями)
На мой взгляд все перечисленные факторы попадают по этот.

Минимизация метрики неуспешности:
1. Увеличение бюджета проекта

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

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

[Sitizen]

Цитата:

Сообщение от vaavr

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

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

Цитата:

Сообщение от Dzemon

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

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

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

[zemlyn]

1)статья написана тяжело, такое ощущение что взяли презентацию, картинки выкинули, а взамен - предложения по 4 строки.

2)

Цитата:

Сообщение от erp_man

У заказчика имеет смысл назначать и менеджера проекта, и директора проекта.

Это точно, также обычная практика - менеджер проекта руководит группой внедрения со стороны заказчика и куратор проекта (на моей практике - главбухи, начальники ПЭО, начальники ИТ . За выделение доп.ресурсов (что бывает крайне редко) обычно отвечает третий человек, реальный топ и тут всё зависит от того, насколько куратор с ним дружит, хех

3)Про человеческий фактор популярно в статьях видел у Ашманова и в "Автоматизации хаоса"

4)если говорить о количественных метриках неуспешного - возмжно хороошо бы на примере пояснить

5)Sitizen - чего уж там мелочиться - "надо делать так как надо, и не надо, так как не надо"

[Dzemon]

Цитата:

Сообщение от erp_man

Цитата:

Сообщение от Dzemon

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

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

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

Все вопросы решались просто с космической скоростью
Вов-вот, о чем и речь!

[e-Car]

Статья консультанта не очень понимающего суть и смысл внедрения информационных систем вообще (и Аксапты, в частности):
"Просто удивительно с какой настойчивостью заказчик иногда стремится решить свои бизнес-проблемы в рамках проекта внедрения ERP – системы: «Вот внедрим систему и заживем припеваючи»."
Заказчик как правило не может реорганизовать деятельность с использованием старых систем. Потому новую и пытается внедрить. В настоящий момент информационная система это инструмент ведения и РЕОРГАНИЗАЦИИ бизнеса. Этот инструмент меняют только, если он не позволяет развиваться компании дальше (или за откаты. но это отдельный разговор).
Хуже того, ситуацию внедрения компания ДОЛЖНА использовать для переосмысления организации своих процессов. Иначе получается внедрение для автоматизации, а не для повышения эффективности.
Неточность описания ТЗ как фактор неуспешности. ТЗ для развивающейся (а иначе зачем внедрять новую систему) компании по определению не может быть точным. Так же как консультант по определению за время, отведенное на диагностику не сможет со всеми тонкостями учесть все процессы и иньюансы компании. Посему расхождения просто неизбежны. Хуже того даже при идеальном описании состояния "как должно быть" (а такое бывает?) это только первое приближение, поскольку при наложении этого "как должно быть" на реализацию в конкретной системе окажется что какие-то ограничения системы диктуют несколько другой "как должно быть". По каждому модулю. В итоге от первоначального ТЗ по-хорошему останутся только общие принципы и пожелания.
Ну и т.д.

[vaavr]

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

[Sergik]

Цитата:

Сообщение от vaavr

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

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

Цитата:

Сообщение от vaavr

...Хочу лишь сказать, что если консультант правильно понял бизнес заказчика, то ТЗ он легко напишет и быстро согласует.
...

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

[RobiBaggio]

Цитата:

Сообщение от vaavr

Хочу лишь сказать, что если консультант правильно понял бизнес заказчика, то ТЗ он легко напишет и быстро согласует.

Как пример. У меня ситуация:
Вроде бы как все делается правильно:
Была диагностика, анализ. Как мне кажется поняли наши ребята, да и я тоже, специфику бизнеса, и требования заказчика правильно. Функциональные требования написали. Все были очень ими довольны, т.к. учли все пожелания клиента. Дальше, написали ТЗ легко, руководитель проекта со стороны заказчика говорит: "Я ниче не понимаю в ТЗ". Хотя ТЗ написано нормально, показаны бизнес-процессы в графике, описаны настройки, принципы формирования отчетов. А вот на согласование ушло двольно много времени.
Хочу только подчеркнуть своим меседжем, что не всегда при правильном подходе, удается делать все быстро и в срок (Кстати проект затягивается уже на 1,5 месяца, и заказчик с этим согласен).
А что касается статьи, то была обощена вся информация, которая гуляет по инету, и которую рассказывают на всех семинарах и треннингах по управлению проетками.
Но все арвно спасибо автору за то, что все объединил и систематизировал.

[vaavr]

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