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

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

успокоили)

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

да не, такое имхо недопустят. думаю цель реально во благо.

оба два.

Прежде чем писать о неудачном внедрении нужно сначала знать мат часть )).
Как переводивший решение по казначейству с 4.6 на 6.0 в Татнефти в 2010-2011 могу сказать что там и до этого 10-ть лет САП работал и после этого получается лет 5-ть, наверно тяжело назвать неудачным решение на котором компания 15-ть лет работала на продуктиве )).

Как обучали нас на курсах по SAP All-in-One этапы быстрого преднастроенного решения следующие:
- показ преднастроенного решения на демо стенде
- определение дельт (гэпов) между преднастроенными решением и вашими БП
- установка системы
- написание проектного решения на эту дельту
- установка преднастроенного решения с данными вашей компании
- настройка и разработки только дельты
- ну и дальше как обычно:
- интеграционное тестирование и обучение
- создание ролей и пользователей, подготовка рабочих мест и загрузка остатков
- подготовка пользовательских инструкций и т.п.
- старт
Для небольшой компании по методологии ASAP Focus ( описано выше ) может и за 4 месяца можно уложится.

Тут ряд коллег с подачи Maksimus набросали список проектных документов: viewtopic.php?f=20&t=91455&start=0

Понятно, что можно обойтись без существенной части документов. Но к чему это приведет:
- Возрастут проектные риски (типа "А вы обещали!" - "А где мы это обещали?")
- Снизится качество за счет отсутствия ряда документов, таких как описание разработок, части инструкций пользователей и т.д.
- Возрастут риски сдачи проекта за счет противодействия пользователей, если не будет инструкций и обучения ("Вот вам готовая коробка, там все настроено как надо, сами разбирайтесь"), или сверка остатков - можно, конечно, ее опустить, но и доверия к системе не будет.
- Возрастет сложность и, соответственно, стоимость сопровождения (как не возрасти, когда куча Zта без описаний что к чему)
- Но за счет этого можно существенно увеличить скорость внедрения и сократить время на реализацию проекта

Если же более-менее следовать проекту в "классическом" понимании (близкому к PMBOK), то в каком-то виде, но надо подготавливать большинство из перечисленных в соседней теме документов. А только на это надо закладывать несколько человеко-месяцев работ, А возможно и лет, если качественно подходить к делу.

С Уважением,
Георгий

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

flint, а к чему этот комментарий?
Насчет 2 пункта я понял, особенно на проектах, где важнее не результат, а сам процесс (к сожалению, есть и такие). Там да - в основном макулаторогенерация, а не реальное достижение целей проекта, саботаж и дикая боязнь ответственности, и важнее кто перед тобой подпись поставил, а не сам акт приемки. И результата зачастую нет, потому что финансирование прекратится - поэтому всем знакомые сентенции "в процессе", "добились" да "улучшили" в пресс-релизах.

А вот по первому пункту, что Вы имели в ввиду? Если "грамотные компании с готовой методологией" им все перечисленные документы делать не надо? Надо! Просто они уже их готовили, им нет необходимости их с нуля разрабатывать, и они представляют какие документы нужны, зачем, что в них писать надо и трудозатраты на их подготовку. И риски, при отсутствии того или иного документа.

Поясните свою мысль, пожалуйста.

С Уважением,
Георгий

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

По первой части вашей фразы. Вы игнорируете то, что каждый проект - уникален. По определению.
По второй части. По моему опыту наиболее правильное распределение трудозатрат находится где-то в районе 1/3 на сами работы - 2/3 на документацию. Без документирования - вы игнорируете серьезные риски, как организационные, так и технические.

Ну, тогда вам надо поработать над умением выражать свои мысли.

Ох ты ё! Я считал, что на бумажную работу 20-25%, ну 30% - это максимум...

С Уважением,
Георгий