AXForum  
Вернуться   AXForum > Прочие обсуждения > forum.mazzy.ru > Обсуждение статей на mazzy.ru
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 13.08.2006, 20:02   #1  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Что же такое «неуспешность» и можно ли для данного понятия ввести количественные метрики. Можно ли оценить факторы, влияющие на неуспешность и как их учитывать в ходе проекта. В настоящей публикации Владимир Аврутин предпринял попытку ответить на эти и другие смежные вопросы.

Подробнее...
http://axapta.mazzy.ru/lib/unsuccess/
__________________
полезное на axForum, github, vk, coub.
Старый 14.08.2006, 13:57   #2  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Довольно поверхностно. Мало уделено внимания "человеческому фактору".
Старый 14.08.2006, 15:10   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Dzemon Посмотреть сообщение
Довольно поверхностно. Мало уделено внимания "человеческому фактору".
Что бы ты добавил (посоветовал добавить)?
__________________
полезное на axForum, github, vk, coub.
Старый 14.08.2006, 17:03   #4  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Да много уже чего писали по этому поводу.
Особо хочется отметить мотивацию сотрудников, особенно среднего слоя менеджмента и отдела ИТ.

И еще о Руководителе Проекта со стороны Заказчика.
Как-то так сложилось, что обычно это человек из ИТ подразделения, занимающийся общением с Внедренцем или Большой Начальник, с Внедренцем не общающийся. Для нормального ведения проекта это должен быть человек РЕАЛЬНО ведущий проект и имеющий реальную власть в организации - могущий принимать ответственные решения. Многие проекты буксуют из-за долгого прохождения распоряжений по инстанциям и нежелании этих инстанций что-либо решать самостоятельно.
Старый 14.08.2006, 19:21   #5  
Sitizen is offline
Sitizen
Участник
Аватар для Sitizen
 
305 / 10 (1) +
Регистрация: 10.01.2006
Собственно ничего нового.
Я бы сократил статью до нескольких предложений.
Факторы неуспешности:
1. Неэффективное управление проектом (под управлением понимается управление временем, изменениями, придметом, рисками, бюджетом, ожиданиями)
На мой взгляд все перечисленные факторы попадают по этот.

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

Все, что предлагает автор по минимизации неуспешности влечет за собой увеличение затрат на проект.
И большинство пунктов относится прстому управлению проектом.
Таки образом упрощаем статью до трех предложений:
Причины неуспешности - плохое управление проектом.
Факторы минимизации неуспешности - эффективное управление проектом.
Все остальное - это форс-мажор.
Старый 15.08.2006, 00:48   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Sitizen Посмотреть сообщение
Таки образом упрощаем статью до трех предложений:
Как-то уж очень... всю религию к непотребству свел...
__________________
полезное на axForum, github, vk, coub.
Старый 15.08.2006, 13:36   #7  
Sitizen is offline
Sitizen
Участник
Аватар для Sitizen
 
305 / 10 (1) +
Регистрация: 10.01.2006
Цитата:
Сообщение от mazzy Посмотреть сообщение
Цитата:
Сообщение от Sitizen Посмотреть сообщение
Таки образом упрощаем статью до трех предложений:
Как-то уж очень... всю религию к непотребству свел...
А я не понимаю, когда суть вещей облекают в излишнюю форму
Старый 16.08.2006, 14:16   #8  
vaavr is offline
vaavr
Участник
 
72 / 16 (1) ++
Регистрация: 07.06.2002
Цитата:
Сообщение от Sitizen Посмотреть сообщение
Собственно ничего нового.
Я бы сократил статью до нескольких предложений.
Факторы неуспешности:
1. Неэффективное управление проектом (под управлением понимается управление временем, изменениями, придметом, рисками, бюджетом, ожиданиями)
На мой взгляд все перечисленные факторы попадают по этот.

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

Все, что предлагает автор по минимизации неуспешности влечет за собой увеличение затрат на проект.
И большинство пунктов относится прстому управлению проектом.
Таки образом упрощаем статью до трех предложений:
Причины неуспешности - плохое управление проектом.
Факторы минимизации неуспешности - эффективное управление проектом.
Все остальное - это форс-мажор.
Как в известном анекдоте: "Ну ничего себе басню сократили".
Помню как в "застойные" годы на все предложения была одна резолюция: "Надо лучше работать". В причинах никто не хотел разбираться.
Старый 16.08.2006, 14:26   #9  
Sitizen is offline
Sitizen
Участник
Аватар для Sitizen
 
305 / 10 (1) +
Регистрация: 10.01.2006
Цитата:
Сообщение от vaavr Посмотреть сообщение
Как в известном анекдоте: "Ну ничего себе басню сократили".
Помню как в "застойные" годы на все предложения была одна резолюция: "Надо лучше работать". В причинах никто не хотел разбираться.
Не вижу связи.
Просто есть два подхода - один, как проект сделать успешным - это описано в руководствах по управлению проектом.
А второй - как проект сделать не неуспешным - собственно берешь и выворачиваешь технолонию управления проектом наизнанку, что, на мой взгляд, и сделал автор статьи.
Старый 21.08.2006, 14:03   #10  
erp_man
Гость
 
n/a
Цитата:
Сообщение от Dzemon Посмотреть сообщение
И еще о Руководителе Проекта со стороны Заказчика.
Как-то так сложилось, что обычно это человек из ИТ подразделения, занимающийся общением с Внедренцем или Большой Начальник, с Внедренцем не общающийся. Для нормального ведения проекта это должен быть человек РЕАЛЬНО ведущий проект и имеющий реальную власть в организации - могущий принимать ответственные решения. Многие проекты буксуют из-за долгого прохождения распоряжений по инстанциям и нежелании этих инстанций что-либо решать самостоятельно.
У заказчика имеет смысл назначать и менеджера проекта, и директора проекта.
Первый решает оперативные задачи управления проектом , второй назначается из числа топов и осуществляет административную поддержку Руководителя проекта, если это необходимо.
Наверное, это единственный реальный выход.

Хотя один раз сталкивался с тем, что еженедельные встречи по статусу проекта проводил ген. директор и он же владелец крупной телекоммуникационной компании- у человека нашлось время на проект. Все вопросы решались просто с космической скоростью
Старый 22.08.2006, 01:22   #11  
zemlyn is offline
zemlyn
Участник
Аватар для zemlyn
 
146 / 44 (2) +++
Регистрация: 28.01.2004
1)статья написана тяжело, такое ощущение что взяли презентацию, картинки выкинули, а взамен - предложения по 4 строки.

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

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

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

5)Sitizen - чего уж там мелочиться - "надо делать так как надо, и не надо, так как не надо"
Старый 22.08.2006, 15:53   #12  
Dzemon is offline
Dzemon
Moderator
 
1,247 / 12 (3) ++
Регистрация: 09.09.2004
Цитата:
Сообщение от erp_man Посмотреть сообщение
Цитата:
Сообщение от Dzemon Посмотреть сообщение
И еще о Руководителе Проекта со стороны Заказчика.
Как-то так сложилось, что обычно это человек из ИТ подразделения, занимающийся общением с Внедренцем или Большой Начальник, с Внедренцем не общающийся. Для нормального ведения проекта это должен быть человек РЕАЛЬНО ведущий проект и имеющий реальную власть в организации - могущий принимать ответственные решения. Многие проекты буксуют из-за долгого прохождения распоряжений по инстанциям и нежелании этих инстанций что-либо решать самостоятельно.
У заказчика имеет смысл назначать и менеджера проекта, и директора проекта.
Первый решает оперативные задачи управления проектом , второй назначается из числа топов и осуществляет административную поддержку Руководителя проекта, если это необходимо.
Наверное, это единственный реальный выход.

Хотя один раз сталкивался с тем, что еженедельные встречи по статусу проекта проводил ген. директор и он же владелец крупной телекоммуникационной компании- у человека нашлось время на проект. Все вопросы решались просто с космической скоростью
Все вопросы решались просто с космической скоростью
Вов-вот, о чем и речь!
Старый 18.09.2006, 01:40   #13  
e-Car is offline
e-Car
Участник
 
22 / 10 (1) +
Регистрация: 21.03.2004
Адрес: Москва
Статья консультанта не очень понимающего суть и смысл внедрения информационных систем вообще (и Аксапты, в частности):
"Просто удивительно с какой настойчивостью заказчик иногда стремится решить свои бизнес-проблемы в рамках проекта внедрения ERP – системы: «Вот внедрим систему и заживем припеваючи»."
Заказчик как правило не может реорганизовать деятельность с использованием старых систем. Потому новую и пытается внедрить. В настоящий момент информационная система это инструмент ведения и РЕОРГАНИЗАЦИИ бизнеса. Этот инструмент меняют только, если он не позволяет развиваться компании дальше (или за откаты. но это отдельный разговор).
Хуже того, ситуацию внедрения компания ДОЛЖНА использовать для переосмысления организации своих процессов. Иначе получается внедрение для автоматизации, а не для повышения эффективности.
Неточность описания ТЗ как фактор неуспешности. ТЗ для развивающейся (а иначе зачем внедрять новую систему) компании по определению не может быть точным. Так же как консультант по определению за время, отведенное на диагностику не сможет со всеми тонкостями учесть все процессы и иньюансы компании. Посему расхождения просто неизбежны. Хуже того даже при идеальном описании состояния "как должно быть" (а такое бывает?) это только первое приближение, поскольку при наложении этого "как должно быть" на реализацию в конкретной системе окажется что какие-то ограничения системы диктуют несколько другой "как должно быть". По каждому модулю. В итоге от первоначального ТЗ по-хорошему останутся только общие принципы и пожелания.
Ну и т.д.
Старый 29.09.2006, 12:38   #14  
vaavr is offline
vaavr
Участник
 
72 / 16 (1) ++
Регистрация: 07.06.2002
Уважаемый e-car.
Уверяю вас, что свои бизнес-проблемы заказчик обычно решает реинженирингом бизнеса, его регламентацией и наймом квалифицированных управленцев.
Консалтинг по этим вопросам обычно проводит консалтинговая компания или крупная компания-внедренец, имеющая мощное подразделение управленческого консалтинга и это делается в рамках отдельного проекта (могу привести множество примеров).
Попытка решения сложных бизнес-задач в рамках проекта внедрения системы является риском, причем трудноуправляемым, который снижает вероятность успешного внедрения, о чем собственно в статье и написано.
По поводу ТЗ хочу заметить, что его надо делать не на этапе Диагностика, а на этапе Анализ. Тезисы о принципиальной невозможности формирования нормального ТЗ оставляю без комментариев.
Хочу лишь сказать, что если консультант правильно понял бизнес заказчика, то ТЗ он легко напишет и быстро согласует.
Ну а если не понял....
Старый 09.10.2006, 14:31   #15  
Sergik is offline
Sergik
Участник
 
136 / 10 (1) +
Регистрация: 25.08.2004
Адрес: Москва
Цитата:
Сообщение от vaavr Посмотреть сообщение
... Уверяю вас, что свои бизнес-проблемы заказчик обычно решает реинженирингом бизнеса, его регламентацией и наймом квалифицированных управленцев.
Консалтинг по этим вопросам обычно проводит консалтинговая компания или крупная компания-внедренец, имеющая мощное подразделение управленческого консалтинга и это делается в рамках отдельного проекта (могу привести множество примеров).
Попытка решения сложных бизнес-задач в рамках проекта внедрения системы является риском, причем трудноуправляемым, который снижает вероятность успешного внедрения, о чем собственно в статье и написано...
Уверяю Вас, что наличие актуальных бизнес - проблем заказчика, на решение которых направлено внедрение или модификация ERP-системы является основной движущей силой проекта и можно даже сказать одним из залогов его успешного завершения. Гораздо большим риском характеризуется внедрение системы, необходимость которой не очевидна и не подкреплена актуальными бизнес - проблемами.

Цитата:
Сообщение от vaavr Посмотреть сообщение
...Хочу лишь сказать, что если консультант правильно понял бизнес заказчика, то ТЗ он легко напишет и быстро согласует.
...
Оптимистичный вывод. "Правильно понять бизнес заказчика" нетрудно квалифицированному консультанту. А вот написать корректное ТЗ и его согласовать - как правило, задача совсем не из легких. С другой стороны, влегкую скомпилированное и быстро одобренное ТЗ скорее всего станет троянским конем для самого проекта на его последующих стадиях.
Старый 09.10.2006, 19:05   #16  
RobiBaggio is offline
RobiBaggio
Участник
Аватар для RobiBaggio
 
285 / 10 (1) +
Регистрация: 16.02.2004
Цитата:
Сообщение от vaavr Посмотреть сообщение
Хочу лишь сказать, что если консультант правильно понял бизнес заказчика, то ТЗ он легко напишет и быстро согласует.
Как пример. У меня ситуация:
Вроде бы как все делается правильно:
Была диагностика, анализ. Как мне кажется поняли наши ребята, да и я тоже, специфику бизнеса, и требования заказчика правильно. Функциональные требования написали. Все были очень ими довольны, т.к. учли все пожелания клиента. Дальше, написали ТЗ легко, руководитель проекта со стороны заказчика говорит: "Я ниче не понимаю в ТЗ". Хотя ТЗ написано нормально, показаны бизнес-процессы в графике, описаны настройки, принципы формирования отчетов. А вот на согласование ушло двольно много времени.
Хочу только подчеркнуть своим меседжем, что не всегда при правильном подходе, удается делать все быстро и в срок (Кстати проект затягивается уже на 1,5 месяца, и заказчик с этим согласен).
А что касается статьи, то была обощена вся информация, которая гуляет по инету, и которую рассказывают на всех семинарах и треннингах по управлению проетками.
Но все арвно спасибо автору за то, что все объединил и систематизировал.
Старый 28.10.2006, 11:55   #17  
vaavr is offline
vaavr
Участник
 
72 / 16 (1) ++
Регистрация: 07.06.2002
Да, согласен, что есть проблемы.
Обычно мы все процедурные вопросы в том числе порядок согласования документов оговариваем в Уставе проекта.
У серьезного заказчика менеджер, который говорит, что ничего не понимает в ТЗ, сильно рискует. К сожалению, сейчас пошел совсем другой заказчик.
А вот у нас по одному крупному проекту другая проблема.
ТЗ написано плохо (пиала другая организация) и заказчик третий раз не принимает Дизайн (трактует неточности ТЗ в свою пользу).
 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 18:31.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.