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

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

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

Чтобы разработать хорошу АБС Вы сами должны очень хорошо понять что же такое БАНК и как он функционирует. Причём выделить именно базовые процессы и второстепенные. Мой опыт также показывает, что когда работаешь с давно сложившейся организацией, где есть опытный давно работающий персонал, то консультанта лучше всего искать именно среди них. И при проектировании системы желательно максимально сохранить уже существующие технологии работ, а не изобретать новые.

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

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

Ещё одна типичная ошибка, которую я и сам раньше делал - попытка разработать систему с большим количеством настроек. То есть так, чтобы не переписывая программу её можно было настраивать на всякие там изменения. Так вот, я в последнем проекте я практически полностью отошёл от этой практики. Количество настроек, которые может изменять пользователь - минимальны. Вся система создаётся в среде Delphi под MS SQL 2000 и поставляется заказчику со всеми исходными текстами. То есть, если возникают какие-то изменения, то меняется исходный код программы и пользователям ставится новый exe файл. Правда, это накладывает особые требования на разработку самой программы и на качественную и полную техдокументацию.
Пока практика показывает, что подход себя оправдывает. Глюков и сбоев в работе гоарздо меньше, чем в предыдущей версии, в которой можно было настраивать практически всё, что хочешь. Да и быстродейтсвие значительно увеличилось. Но это, опять же, возможно, когда чтко выделишь базовые процессы и вторичные. Базовые процессы закладываются в основу системы, а все вторичные делаются как надстройка. Зачастую это даже отдельные приложения, которые работают с основной базой данных (чтобы их было потом проще менять). Кстати, для втоичных процессов всё равно приходится до определённой степени делать механизм настройки, но это всё равно получается меньше, чем если писать программу полностью настариваемую на все случаи жизни.

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

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

Да, ещё одна типичная на мой взгляд ошибка - попытка делать одно большое супер пупер приложение. То есть, пользователю ставится один exe файл, в котором забиты все возможные функции. Но при этом реальный пользователь будет из этой программы использовать только небольшую часть. В качестве примера см. ту же 1С.
Мне кажется, что с точки зрения разработки, внедрения и поддержки более правильно разделять прокт на несколько программ, которые согласованно работают с общей БД. Естественно, что они выполняются как единое целое с использованием общих программных модулей и т.д. Но лепить всё в один большой exe-шник с кучей форм и функций - самому себе создавать лишние проблемы.

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

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

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

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

Кстати, иногда в такой работе очень нехватает не аналитика, а хорошего психолога.

Это будет не аналитик а знаток предметной области - это не одно и тоже!
Иными словами я хочу с помощью этого человека навести мосты между предметной областью/постановкой и проектированием/реализацией

Ах вон вы о чём. :) Извиняюсь. я в очередной раз "смерил по себе". Мне в большинстве случаев обычно нужен как раз "знаток предметной области", поскольку дальше я уже сам в состоянии отобразить куда требуется.

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

У меня, кстати, был опыт заказной разработки, когда нам заказывали именно систему в исходных текстах на Delphi, которую потом вели и дорабатывали программисты заказчика. Просто там было ну очень много работы, а у них штат был маленький и в этой предметной области они хуже нас разбирались. Плюс сама контора совсем не программисткая (и даже не компьютерная). То есть, для них данная система - внутренний инструмент. В итоге все остались довольны результатом.

Ну опять понты :) Да я тоже думаю что в состоянии и достаточно не плохом...

Но опять же - мне хотелось бы видеть как свою работу выполнил бы профессионал!

Ну почему же сразу "понты!". :)
В своё время я тоже много чему научился у других людей, в том числе и некоторым весьма неочевидным вещам, и некотрым мелочам, которые существенно облегчают работу. Но есть некий момент, так сказать "точка насыщения", после которой желание всё время "видеть как свою работу выполнил бы профессионал" в большей степени есть неверие в свобственные силы и возможности. Только не воспринимай это за "наезд" и не обижайся пожалуйста. Это скорее мысли вслух. Просто в последнее время часто приходится сталкиваться с молодыми толковыми ребятами, которые вместо того, чтобы самим дело делать, всё время бегают "видеть как работает профессионал" или начинают спрашивать совет на каждом мелком шаге.

Опять же, хочешь получить совет - задавай конкретные вопросы. Есть ведь уже какие-то наработки. Вот и выкладывай что непонятно на форумах, а потом смотри дельные замечания и советы, если хочешь "дешёвое" решение, как ты написал. Поскольку сама эта фраза серьёзного человека останавливает. Время хорошего специалиста, который действительно Профессионал, достаточно дорого (и он это прекрасно знает). Так что такой челвоек если и даст совет, то между делом, не особо вдаваясь во все мелкие подробности. Ну либо его нужно нанимать и его время оплачивать, но тогда это уже не будет "дешёвое решение". :)

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

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

Планирование и анализ при неверных исходных данных смысла не имеют.