Alexey KudinovЗакладываться на то, что может быть "вообще все что угодно" можно, но не нужно.
Боюсь, Вы не уловили ключевого аспекта: с моей точки зрения, в большинстве случаев не нужно "закладываться" (то есть предпринимать какие-то специальные усилия по этому поводу), нужно оставлять себе свободу действий на тот момент, когда и если наконец потребуется принимать решение. Дело в том, что когда требуется "расширить" узкую систему, довольно часто оказывается, что ранее были приняты совершенно необязательные решения, которые тогда были в лучшем случае "чуть проще", а сейчас заставляют либо серьезно переделывать, либо придумывать кривые обходы.

Alexey KudinovОчень уж категорично... Случаи таки бывают разные.
Таки бывают :) Но тут есть еще один аспект. Позволю себе аналогию - это из рассказа одного из наших летчиков-испытателей. Во время войны, летит куда-то пассажиром, большую часть полета проводит в кабине болтая с пилотами, перед посадкой у транспортника не выходит одна из ног шасси. Он проводит быстый инструктаж типа - все нормально, садись как если бы обе ноги нормально вышли, ничего страшного не будет. И у него там есть такая фраза - мол, я думал, не сказать ли, что перед касанием стоит чуть наклонить самолет в сторону здоровой ноги, но решил что не стоит - обычный строевой летчик запросто может перестараться, зацепить крылом землю и всех угробить, пусть лучше садится так.

К чему этот рассказ. Я полагаю, что информация, утверждения итп кроме естественного деления истинно/ложно следует рассматривать еще в одном разрезе, условно назовем удачно/неудачно. Суть в том, что в жизни бывает так, что из вообще говоря ложного утверждения следуют правильные с практической точки зрения результаты, и наоборот, формально правильная мысль может приводить к практически неудачным последствиям.

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

Alexey Kudinovесли честно, со стороны мне показалось, что и вы и Bogdanov Andrey говорите об одном и том же.
Безусловно. Разница в акцентах и как мне кажется, в изначально разном понимании степени универсальности, подразумеваемой в конкретном случае.

Alexey KudinovОтносительно истории с программой для NMT- хотелось бы еще послушать точку зрения вашего руководства (понимаю, что вряд ли это возможно), и их обоснование почему вам говорили делать так, а не иначе.
Вряд ли они выскажутся, не потому что отсутствуют - этот форум в той фирме читают - но потому, что вряд ли помнят ту эпопею так хорошо, как я - я принимал ее очень близко к сердцу, а для них это был "маленький дешевый проект".

Bogdanov AndreyЕстественно можно придумать универсальную учетную модель, в которую удастся запихнуть и банковский бухучет и товарный учет на складе,
Ага. Собственно, как я и ожидал:

softwarerи как мне кажется, в изначально разном понимании степени универсальности, подразумеваемой в конкретном случае.

Bogdanov AndreySAP R3 и Oracle Applications скорее не готовые системы, а "конструкторы" для разработки систем.
Не скажу ничего о SAP, но насчет OEBS не согласен. Разумеется, при остром желании можно сотворить руками "OEBS который и на OEBS-то не похож", но это нисколько не означает "конструкторности".

Bogdanov AndreyНе хотел обидеть уважаемый EBS, просто на мой взгляд его упоминание в этом топике равносильно упоминанию Oracle - мало кто пишет свои реляционные СУБД, большинство использует готовые наработки. Мне казалось, что автор все-таки говорил о другом "уровне" наработок.
Я нисколько не обижаюсь за неинтересный мне EBS, но мне кажется что у "O"EBS и "O"RDBMS существенно разный уровень "наработанности".

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

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

AlexTheRavenIMHO потому, что ресурсы на фундаментальные исследования, и даже на изучение результатов уже проведённых фундаментальных исследований, при создании обычных учётных систем не предусмотрено.
Я бы усилил это утверждение. Допустим, идет внедрение какого-нибудь OEBS, надо например написать два отчета. Если внести в план первый отчет - пять дней, второй отчет - пять дней, это легко, просто и не вызывает вопросов. Если же внести в план, допустим, "некая фундаментальная работа под оба этих отчета" - три дня, первый отчет - три дня, второй отчет - два дня, то окажется, что разработчик создал себе проблемы на пустом месте: ему это не нужно, он просто сократил себе оплачиваемое рабочее время, и мало того, клиент еще и встанет на дыбы и скажет "чего это вы делали непонятно что, оплачу только три дня по первому отчету и два дня по второму". Вот такая вот загогулина :(

FrankieКакой кошмар, неужели кругом одни идиоты?!
Нет, не одни. Но встречаются достаточно часто, чтобы возникали проблемы.

FrankieЯ бы в такой ситуации составил план согласно первому случаю, а делал согласно второму :)
И в результате через пять дней пользователь сказал бы: по плану первый отчет уже должен быть готов. Где он?? :))

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