AXForum  
Вернуться   AXForum > Рынок > Методология внедрения
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 11.12.2015, 12:19   #1  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от AXcons Посмотреть сообщение
...технологии внедрения на рынке грамотной нет. ....
Нет, и не особо будет. Потому, что любой вендор под технологией внедрения понимает технологию проектного документооборота. Отсюда все эти безумные "чеклисты", "степы" и прочие чудеса англо-русского языка. А включаешь - не работает

Технология собственно внедрения по определению не вендороцентрична, а посему производителю программы неинтересна. Технологии же управления сферическими проектами в вакууме вырождаются в абстрактный опять-таки документооборот - со всеми этими "картами риска", "запросами на изменение" и прочей бухгалтерией. Некоторые штуки вполне себе могут работать, однако на вопрос, как вам запустить книгу покупок до 20 числа (или что делать, если 21го она сглючит, или что вам делать в случае отключения электричества на складе, и т.д и т.п.) - никакая система документооборота вам не скажет.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 14.12.2015, 12:58   #2  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
(вставлю свои пять копеек)
Основной свой опыт с AX получил на клиенте и, глядя с той колокольни, на эту дискуссию, могу сказать: две, нет, три основные проблемы взаимоотношений клиент/консалтинг на проекте - это отсутствие бизнес-аналитика со стороны клиента, умеющего работать толмачом между специалистами двух сторон (перевод с птичьего на другой птичий); отсутствие прикладника со стороны консалтинга; идиотская приверженность некоторых представителей клиента к «рюшечкам» и нежелание тратить оставшиеся нервы специалистами консалтинга на борьбу с рюшечками.
Запустите основные процессы, научите пользователей работать, покажите преимущества и расскажите, как малой кровью обойти недостатки. О рюшечках и прочей рихтовке задумайтесь потом. Очень часто альбом процессов и альбом документов при разработке выливается в следующее закидывание помидорами: «- Вы не сказали, что это нужно (или что нужно учесть это и это). - А вы не спросили об этом.» Да чтобы спросить, надо знать, о чем спрашивать.
Специалисты клиента забывают или не хотят (иногда и специально) раскрывать все «секреты»: «Вот не скажу, может и останемся в знакомой среде». Высшее руководство, заинтересованное в переходе на новую систему, спрашивать, за редким исключением, бесполезно, ибо они нарисуют сферического коня в вакууме, свою розовую мечту, далекую от истины. Итоговый документ превращается в декларацию о намерениях с легким абрисом «болевых точек». И это не устраивает обе стороны: «Плохой консалтинг, забыли … (список на n листах)»; «Проблемный клиент, список дополнительных работ на n листах без расширения бюджета». Хорошо, если у консалтинговой компании есть уже опыт в выбранной сфере автоматизации. Уже наступали на грабли и знают, что надо не забыть спросить. Мелкие отличия сильно не скажутся. А если нет? Вот тут и начинается игра в русскую рулетку, а всего-то надо одного толмача, который не будет относиться к рискам проекта.
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании.
За это сообщение автора поблагодарили: fedka (1).
Старый 14.12.2015, 14:04   #3  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Коллеги, по следам дивной темы По мотивам общения с Майкрософтом решил скопировать часть интересных высказываний в эту отдельную ветку. Мне кажется, что пост KiselevSA очень верно раскрывает суть, почему методология ведения проекта из руководсва "как сделать то, что хочет Заказчик в срок и с минимальными рисками" превращается в талмуд "как учесть все закидоны клиента и защитится от "вы этого не учли, вы того не учли, а вот еще это и это сделайте в рамках текущего проекта" - то, о чем пишет Дмитрий.

С Уважением,
Георгий
Старый 14.12.2015, 14:55   #4  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
Запустите основные процессы, научите пользователей работать, покажите преимущества и расскажите, как малой кровью обойти недостатки. О рюшечках и прочей рихтовке задумайтесь потом.
Да, очень правильно было бы задумываться о том, что система должна работать Не галки должны быть проставлены и не отчёты должны быть нарисованы, а именно "система должна работать" А "система" - это, как правило, не только и не столько программа... Вот об этом методология вендора никогда и не скажет - потому, что для производителя программы система = программа. А это не так.

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

Сферические же в вакууме методологии управления проектами существуют для успешного проведения задницеприкрывательных мероприятий, и со своей задачей справляются на все 100%. Задачи "система должна работать" здесь тоже нет в помине.
__________________
All information in this post is strictly confidential. If you have read it in error, please forget it immediately.
Старый 14.12.2015, 15:13   #5  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,766 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
О да, напишите в ТЗ "Система должна работать" и главное, подпишите это у заказчика.

Такое у нас было только с клиентами с которыми 100% взаимопонимание + доверие + взаимное обучение друг-друга.
И с отраслевыми клиентами, когда из узкой специализации отрасли не спрыгнешь, потому что всё регламентировано бизнесом. При этом необходимо присутствие отработанного отраслевого решения.
Старый 14.12.2015, 15:15   #6  
KiselevSA is offline
KiselevSA
Злыдни
Аватар для KiselevSA
Злыдни
Лучший по профессии 2015
 
958 / 333 (13) ++++++
Регистрация: 25.01.2002
Адрес: Москва
Цитата:
Сообщение от komar Посмотреть сообщение
Да, очень правильно было бы задумываться о том, что система должна работать Не галки должны быть проставлены и не отчёты должны быть нарисованы, а именно "система должна работать" А "система" - это, как правило, не только и не столько программа... Вот об этом методология вендора никогда и не скажет - потому, что для производителя программы система = программа. А это не так.
Отчасти не соглашусь, ибо методология вендора рассчитана на 100% совпадение всех входных условий: формирование команд заказчика и исполнителя, назначение ключевых фигур. опыт специалистов и, обратите внимание, достаточно подробного описания БП хотя бы ASIS. Ну, т.е., когда все шестеренки в механизме есть, правильно смазаны и не имеют "сломанных", точнее лишних, зубов. Для западного менталитета, успех корпорации прежде всего, такой подход будет рабочим, а вот перенос его на российскую действительность страдает на все две (или даже четыре) ноги.
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании.
Старый 14.12.2015, 15:16   #7  
Vals is offline
Vals
Аманд
Аватар для Vals
Компания АМАНД
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2009
 
1,766 / 507 (20) +++++++
Регистрация: 27.02.2002
Адрес: Pass partout, Москва
Цитата:
Сообщение от komar Посмотреть сообщение
Сферические же в вакууме методологии управления проектами существуют для успешного проведения задницеприкрывательных мероприятий, и со своей задачей справляются на все 100%. Задачи "система должна работать" здесь тоже нет в помине.
Поддерживаю. Даже лекция в МИРБИСе была на эту тему

Нарисуй картину
Студенты тоже говорили - нарисуй картину, я им изображал как Мог, а Мог был известным художником
http://www.e-xecutive.ru/blog/Vals/2855.php

Последний раз редактировалось Vals; 14.12.2015 в 15:35.
За это сообщение автора поблагодарили: mazzy (2), gl00mie (1).
Старый 14.12.2015, 20:12   #8  
Bobkov is offline
Bobkov
Участник
Аватар для Bobkov
 
238 / 299 (10) ++++++
Регистрация: 30.10.2002
Адрес: München
О работающей системе
Цитата:
Сообщение от Vals Посмотреть сообщение
О да, напишите в ТЗ "Система должна работать" и главное, подпишите это у заказчика.
Самое смешное, что именно это и нужно и заказчику, и исполнителю. В нормальном ТЗ должна быть определено, что понимается в рамках данного проекта под Системой и определены критерии приемки готовой Системы заказчиком. Когда-то мне повезло читать подготовленный Сергеем Мазуркиным проект договора на маленькую системку, и там в приложении по сути было именно такое ТЗ - что такое в данном случае "система" и что такое "работает". Было очень приятно читать
Старый 15.12.2015, 10:57   #9  
fedka is offline
fedka
Участник
 
69 / 15 (1) ++
Регистрация: 12.04.2007
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
отсутствие бизнес-аналитика со стороны клиента, умеющего работать толмачом между специалистами двух сторон (перевод с птичьего на другой птичий);
Полностью согласен!
Но вот по рюшечкам - я считаю что на начальном проекте они также важны - дабы мотивировать сотрудников заказчика. Нужен "бизнес аналитик" и эксперты в деятельности организаций. Экспертов то и надо мотивировать - а люди за ними потянутся.
Старый 19.12.2015, 00:23   #10  
AXcons is offline
AXcons
Участник
 
442 / 112 (4) +++++
Регистрация: 21.05.2015
Адрес: Москва
Цитата:
Сообщение от KiselevSA Посмотреть сообщение
(вставлю свои пять копеек)
Основной свой опыт с AX получил на клиенте и, глядя с той колокольни, на эту дискуссию, могу сказать: две, нет, три основные проблемы взаимоотношений клиент/консалтинг на проекте - это отсутствие бизнес-аналитика со стороны клиента, умеющего работать толмачом между специалистами двух сторон (перевод с птичьего на другой птичий); отсутствие прикладника со стороны консалтинга; идиотская приверженность некоторых представителей клиента к «рюшечкам» и нежелание тратить оставшиеся нервы специалистами консалтинга на борьбу с рюшечками.
Запустите основные процессы, научите пользователей работать, покажите преимущества и расскажите, как малой кровью обойти недостатки. О рюшечках и прочей рихтовке задумайтесь потом. Очень часто альбом процессов и альбом документов при разработке выливается в следующее закидывание помидорами: «- Вы не сказали, что это нужно (или что нужно учесть это и это). - А вы не спросили об этом.» Да чтобы спросить, надо знать, о чем спрашивать.
Специалисты клиента забывают или не хотят (иногда и специально) раскрывать все «секреты»: «Вот не скажу, может и останемся в знакомой среде». Высшее руководство, заинтересованное в переходе на новую систему, спрашивать, за редким исключением, бесполезно, ибо они нарисуют сферического коня в вакууме, свою розовую мечту, далекую от истины. Итоговый документ превращается в декларацию о намерениях с легким абрисом «болевых точек». И это не устраивает обе стороны: «Плохой консалтинг, забыли … (список на n листах)»; «Проблемный клиент, список дополнительных работ на n листах без расширения бюджета». Хорошо, если у консалтинговой компании есть уже опыт в выбранной сфере автоматизации. Уже наступали на грабли и знают, что надо не забыть спросить. Мелкие отличия сильно не скажутся. А если нет? Вот тут и начинается игра в русскую рулетку, а всего-то надо одного толмача, который не будет относиться к рискам проекта.
Проблема не учтенных требований очень легко решается договором с плавающим бюджетом. То есть, бюджет на разработку определяется не в момент подписания договора, а по согласованному конкретному перечню доработок. Тогда и проблем не будет - ну забыли что-то - ок, включили в следующий этап, доработали.

Еще есть такой трюк (если все-таки бюджет надо как-то зафиксировать) - в бюджет закладывать специальную статью - дополнительные требования. И заложите хорошо там - 10-20% от всего бюджета на разработку. И тогда, если у вас возникла такая ситуация с требованиями - оп, а у вас под это есть бюджет.
У меня называлась такая статья "Мелкие доработки по требованиям пользователей". Но у меня неучтенных требований не было. Там действительно было на такие вещи, как доработка пользовательского интерфейса, и какие-то мелочи. Потому что мы тщательно обследование делали. Ну сначала было, конечно, первые года 3 работы в консалтинге. А потом уже нет. Никаких сюрпризов на запуске в эксплуатацию.

Также для этого прототип системы хорошо на этапе дизайна настраивать и показывать заказчику. Причем, конечному пользователю. Вот они когда систему видят, сразу понимают, что все реально серьезно и начинают до всего докапываться. И вот на этом показе вы соберете ВСЕ требования - и которые есть, и которых нет - они вспомнят все бизнес-процессы, которые у них были, есть, и даже которые только будут
Старый 19.12.2015, 13:20   #11  
miklenew is offline
miklenew
Участник
Аватар для miklenew
MCBMSS
1C
Лучший по профессии 2009
 
1,688 / 433 (18) +++++++
Регистрация: 10.07.2006
Адрес: г. Ликино-Дулёво
Цитата:
Сообщение от AXcons Посмотреть сообщение
Также для этого прототип системы хорошо на этапе дизайна настраивать и показывать заказчику. Причем, конечному пользователю.
Перечитал несколько раз. Задался вопросом: Он реально имеет ввиду дословно то, что написал?
Прототип системы??? - ого. Может прототип процесса.
Дизайном заниматься на этапе прототипа?
Прототип нужен для ознакомления с стандартными возможностями и понимания чего нет и придётся делать самим. Какой тут дизайн? Можно конечно на этом этапе топтаться месяцы... Даже сталкивался раз с таким. Бред.
Конечному пользователю? Вот одна из бед аксапты. Давайте тысячу раз по кругу походим.
Как я делаю.
1) Делаю прототип процесса для себя. На пустой базе или демо, разные бывают варианты. Смотрю чё сходиться, чё не сходиться.
Чё не сходится, ищу ключевого пользователя. Сидим чешим репу.
Потому что бывали случаи, что мне казалось не логичным после разговора с пользователем оказывалось не лишённым логики.
Какой бы ни был процент покрытия типовыми средствами идём на следующий этап.
2) Ввод начальных данных. Доработка. Согласование с ключевым пользователем процесса. Дизайн и другие мелочи.
3) Руководство пользователя ->Обучение. Вот здесь уже конечный пользователь. Снова доработка дизайна, возможно изменение функционала. Но суть вся основная работа должна быть сделана до. Например с начальником отдела. У конечного пользователя должно быть ощущение, что его ставят перед фактом, что завтра он будет работать по этому процессу. Это будет не через месяц, два или год, а ближайшее время. Иначе начинается брожение мозгов, обсуждение каких то пустых вещей.
4) Запуск. Параллельно создание средств анализа. Исправление багов. Баньтики.
5) Поддержка.
Переходим к следующему отделу или следующему процессу.
__________________
Энергия молодых и неравнодушных способна изменить мир к лучшему.
Старый 19.12.2015, 16:48   #12  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
2,164 / 1293 (48) ++++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Попробую задать вопросы со стороны клиента.
Цитата:
То есть, бюджет на разработку определяется не в момент подписания договора, а по согласованному конкретному перечню доработок.
Назовите мне бюджетного контролера, который даст согласие на подписание такого контракта.
Цитата:
И тогда, если у вас возникла такая ситуация с требованиями - оп, а у вас под это есть бюджет.
А если не уложились в это отклонение?
Цитата:
Никаких сюрпризов на запуске в эксплуатацию
Что же это за компания?
Цитата:
Вот они когда систему видят, сразу понимают, что...
Опять же вопрос: "Что же это за компания?". За 25 лет работы ни разу не видел чтобы по демонстрационному примеру ВСЕ СРАЗУ поняли что это там происходит.
Цитата:
И заложите хорошо там - 10-20% от всего бюджета
В бюджете записать сумму 234520 евро, и указать, что 10-20% отклонений? У бюджетного комитета тут же возникнет вопрос почему сумма до 10 евро и отклонения 23-46 тысяч?
Вы уверены, что оперируете реальными проектами, а не "сферическими конями в вакууме"?

Последний раз редактировалось Raven Melancholic; 19.12.2015 в 16:55.
Старый 25.12.2015, 23:28   #13  
AXcons is offline
AXcons
Участник
 
442 / 112 (4) +++++
Регистрация: 21.05.2015
Адрес: Москва
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Попробую задать вопросы со стороны клиента.

Назовите мне бюджетного контролера, который даст согласие на подписание такого контракта.

А если не уложились в это отклонение?

Что же это за компания?

Опять же вопрос: "Что же это за компания?". За 25 лет работы ни разу не видел чтобы по демонстрационному примеру ВСЕ СРАЗУ поняли что это там происходит.

В бюджете записать сумму 234520 евро, и указать, что 10-20% отклонений? У бюджетного комитета тут же возникнет вопрос почему сумма до 10 евро и отклонения 23-46 тысяч?
Вы уверены, что оперируете реальными проектами, а не "сферическими конями в вакууме"?
У меня несколько таких контрактов было с разными клиентами, ни у кого вопросов не было. Причем такой договор подписывался гораздо легче, чем обычный фикс прайс.
Старый 25.12.2015, 23:34   #14  
AXcons is offline
AXcons
Участник
 
442 / 112 (4) +++++
Регистрация: 21.05.2015
Адрес: Москва
Цитата:
Сообщение от miklenew Посмотреть сообщение
Перечитал несколько раз. Задался вопросом: Он реально имеет ввиду дословно то, что написал?
Прототип системы??? - ого. Может прототип процесса.
Дизайном заниматься на этапе прототипа?
Прототип нужен для ознакомления с стандартными возможностями и понимания чего нет и придётся делать самим. Какой тут дизайн? Можно конечно на этом этапе топтаться месяцы... Даже сталкивался раз с таким. Бред.
Конечному пользователю? Вот одна из бед аксапты. Давайте тысячу раз по кругу походим.
Как я делаю.
1) Делаю прототип процесса для себя. На пустой базе или демо, разные бывают варианты. Смотрю чё сходиться, чё не сходиться.
Чё не сходится, ищу ключевого пользователя. Сидим чешим репу.
Потому что бывали случаи, что мне казалось не логичным после разговора с пользователем оказывалось не лишённым логики.
Какой бы ни был процент покрытия типовыми средствами идём на следующий этап.
2) Ввод начальных данных. Доработка. Согласование с ключевым пользователем процесса. Дизайн и другие мелочи.
3) Руководство пользователя ->Обучение. Вот здесь уже конечный пользователь. Снова доработка дизайна, возможно изменение функционала. Но суть вся основная работа должна быть сделана до. Например с начальником отдела. У конечного пользователя должно быть ощущение, что его ставят перед фактом, что завтра он будет работать по этому процессу. Это будет не через месяц, два или год, а ближайшее время. Иначе начинается брожение мозгов, обсуждение каких то пустых вещей.
4) Запуск. Параллельно создание средств анализа. Исправление багов. Баньтики.
5) Поддержка.
Переходим к следующему отделу или следующему процессу.

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

У каждого может быть свой подход. Называть бредом чужую хорошо работающую технология не стоит. Особенно только из-за того, что вы не поняли что написано.
Старый 26.12.2015, 20:24   #15  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от AXcons Посмотреть сообщение
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Попробую задать вопросы со стороны клиента. Опять же вопрос: "Что же это за компания?". За 25 лет работы ни разу не видел чтобы по демонстрационному примеру ВСЕ СРАЗУ поняли что это там происходит.
В бюджете записать сумму 234520 евро, и указать, что 10-20% отклонений? У бюджетного комитета тут же возникнет вопрос почему сумма до 10 евро и отклонения 23-46 тысяч?
Назовите мне бюджетного контролера, который даст согласие на подписание такого контракта. А если не уложились в это отклонение?
У меня несколько таких контрактов было с разными клиентами, ни у кого вопросов не было. Причем такой договор подписывался гораздо легче, чем обычный фикс прайс.
Вы, наверно, какой-то секрет знаете С такими секретными сведениями - и отсиживаться на клиенте... "Оставайтесь! Будете гениальным механиком планеты" руководителем проектов
Старый 27.12.2015, 00:58   #16  
AXcons is offline
AXcons
Участник
 
442 / 112 (4) +++++
Регистрация: 21.05.2015
Адрес: Москва
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Вы, наверно, какой-то секрет знаете С такими секретными сведениями - и отсиживаться на клиенте... "Оставайтесь! Будете гениальным механиком планеты" руководителем проектов
Кое-что знаю, да. Когда-нибудь, наверное, вернусь в консалтинг. А пока отдохну на клиенте

Последний раз редактировалось AXcons; 27.12.2015 в 02:06.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Какая методология лучше в случае "Сначала сделайте, а мы посмотрим" slava09 Курилка 64 24.07.2015 16:40
Методология распределения рабочего времени консультанта / программиста ushastik Курилка 12 24.02.2004 09:22

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

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

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 04:44.