Необходим совет.
Идет внутренний проект, НО процесс документирования, честно говоря, не поставлен. Хочется пока не поздно навести порядок. Подскажите как удобнее и правильнее задокументировать проект (систему)?

План проекта есть, инструкции пользователей тоже, частично есть концептуальные проекты. Но вот роль концептуального проекта на внутреннием проекте размыта. Хочется все структурировать и привести к тому как должно быть.

попробуйте взять стандартный ASAP и посмотреть его структуру и его артефакты

Это отсыл к какому конкретно курсу?

https://websmp202.sap-ag.de/asap
не знаю как сейчас, но раньше его можно было скачать

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

Хоть внутренний проект, хоть проект с привлечением консалтинга, хоть полностью внешнее выполнение - первым этапом ОЧЕНЬ важно определиться с набором и форматом документации.

ASAP - поможет реальными примерами!

Естественно, я не пытаюсь уговорить использовать ВСЕ, что предлагает ASAP.
Но подобрать для себя набор шаблонов очень стоит. На базе примеров ASAP, на базе примеров из других проектов, даже на примере внутрикорпоративных стандартов - подготовить шаблон описания бизнес-процесса, шаблон технического задания на разработку, протокол тестирования.
Выработать шаблон (или найти инструмент) для реестра задач и их статусов (аналогично - список проблем/открытых вопросов).
Разработать процедуры изменений. Правила переноса транспортов. Регламент ведения разработок - инициализация, обоснование необходимости, стандарты оформления.

Могу продолжать, но проще начать именно с того, что взять набор ASAP и посмотреть на его наполнение документами, шаблонами....

На сегодняшний день, есть следующие документы:
1) Концептуальный проект - это как документ, который фиксирует общий дизайн той или иной области (Закупки, Сбыт, Финансы и т.д.)
2) Техническое задание - как документ, который фиксирует подзадачи. Причем ТЗ может быть как на разработку (программирование), так и на настройку. Здесь же в ТЗ прописываются результаты тестирования.
3) Операционные инструкции - тут все понятно.
4) Акт ввода бизнес-процесса в эксплуатацию - это как веха, которая позволяет отчитаться за реализованный БП.

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

Инструмент/шаблон с реестром и статусом работ/задач я вот, признаться честно, упустил из вида совсем, а это ой как пригодится. Общий план внедрения конечно есть, Но вот статусы работ зачастую не понятны.

Спасибо.

а согласие руководства на удвоение бюджета сопровождения вы получили?
знаете крылатую фразу незабвенного С.Полонского?

Отвечу на ваш вопрос так: "У нас внутренний проект".
И расскажите про фразу

Фраза наверно про "миллиард"?

миллиард

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

Неблагодарное дело - это когда настройки и наработки не документированы, а человек из внутренней команды ушел в сторонний консалт.

а где тут "неблагодарность"? что документирование настроек посчитали излишним? что человек решил повысить обеспеченность своей семьи? но это же бизнес, а не хухры-мухры!

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