Матчасть. Если так будет - или консультанты, или руководители проекта - некомпетентны. Особенно, когда на проекте разработку ведёт более двух человек.

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

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

Yanvladimirovich, скажите сколько у вас в компании BW-ников, с которыми вы работаете в связке? У меня почему-то сложилось впечатление, что вы одинокий воин в поле.

Работа в стиле "сделать в разработческой системе, продумать всё как следует, удалить всё что не нужно, удалить всё и сделать всё заново" при условии, что разработкой в BW занимаются одновременно человек 10, приведет вас к куче конфликтов с коллегами. А это гораздо хуже любых технических проблем, с которыми вы можете столкнуться

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

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

Это отдельно можно рассказать. Скажем, тут была идея реализовать по принципу "вся логика на трансформациях, отчёт имеет три признака: дата отчёта, номер строки, номер столбца". Возражения, что при ошибке в ABAP коде придётся перезакачивать весь куб (10 млн записей), пытались замять чем-то вроде "ну, моё дело предложить этот вариант, а твоё уже без ошибок написать!". Возражения, что при изменении ТЗ будет нужно перезакачивать куб, тоже заминают ("ну это у нас сейчас ТЗ меняется раз в неделю, а потом этого не будет").

Дальше я уже который месяц пытаюсь доказать слабую работоспособность, реализуемость этой фантастичной идеи. Например, тем что у нас в отчёте считается клетка через нелинейную формулу над некумулятивным показателем до агрегации, условно, по модулую он берётся. Если мы начнём хранить его на каждый день - будет не 10 млн записей за три года, а 1 млрд записей. И я имел дело с такими кубами, это АД - их нельзя перегрузить, ошибки в реализации приходится компенсировать отчётами, и так далее...

Сами решайте, один я или нет.

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

Я не могу представить ситуацию, когда что-то делают 10 человек и они одновременно делают "всё сразу". Есть разделение труда.

Один правит основные данные, другой делает отчёты. И они друг от друга весьма зависимы.

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

Почитайте про управление проектами в конце концов и не смешите других своими агрессивными и непрофессиональными высказываниями.

Ещё раз - почему нельзя нарисовать кубы в системе разработки, а не на бумаге?

Почему если разработчики сядут и начнут писать на бумаге - они договорятся? Почему, если они сядут за сервер, они не смогут договорится?

Что магическим образом меняет бумага?

"Потому что так принято, а ты дурак"

Ну, спасибо за ответ