<<Даже в России они не единственный банк с большим числом систем.>>В России это уж точно самый большой банк.  Причем своих ближайших конкурентов превосходит в разы.    <<//Ну и при таких размерах команд разработчиков, их уровень, очевидно, далек от гениальности.Тут хотя бы честно. Отсюда ожидание создания “уникального ПО” вежливо скажем несколько завышены.>>Да нет.   Значительную часть работы и должны делать обычные работники.  << Участники проекта подчиняются руководителю проекта.>>Участники проекта-то да, руководителю.   Но главбух это заказчик проекта.И две разные системы имеют двух разных заказчиков и два разных проекта, отличающиеся по срокам и целям. <<. До глав бухов и замов по производству доходит результат проекта, размещенный на проме.>>В самом деле? А если главбуха результат не устроит?Я напоминаю, в моем примере главбух это заказчик.  И он будет требовать демонстрации еще на этапе прототипа.  И будет осуществлять приемку работы. И без его подписи вообще никакого прома не будет. <<Глав бухи и замы производства могут поставить задачу подчиненным участия в постановке ТЗ и приемке результатов.>>Ну да, в текущей деятельности  будут участвовать больше подчиненные.  Но финальная подпись будет за главбухом.Но я-то не про то, кто будет принимать результаты. А про то, что у двух разных интегрирующихся систем эти приемщики будут разными. И их цели разные. А потому интеграция между ними это не только технический, но еще организационный, а часто и политический вопрос. <<Пожалуйста, давайте не будем про кодировку. А то другие подумают про разные языковые стандарты представления данных и их конвертацию. Давно уже единая кодировка.>>Да пожалуйста, хоть горшком назови.На всякий случай еще раз объясню. Я про то, что насос в одной системе имеет код Н-1-2345, а в другой  Н-13-3424-К-23. И размерность внутреннего ID у них тоже разная.  И одно к другому не всегда легко приводится. <<//И понесли в продуктив 9, а они без отмененного десятого где-то навернулись. И не предусмотреть это никак.>>Отлично предусмотреть. Называется архитертурная схема интеграции систем и описание обмена>>Думаете, от того, что это как-то названо, ситуация сама как-то улучшается?Если один пакет в продуктив не поехал, а 9 поехали, то единственный способ гарантировать стабильность, это отложить переезд еще на цикл и оттестировать эти 9 отдельно.А в сбере переносы в прод достаточно регулярны. Уже точно не помню, но кажется мелкие исправления ежемесячно, крупные пакеты раз в 3 месяца. И это во всей той сотне систем, которые там есть. //А в сбере этих систем дохрена.>>Это и есть огромный недостаток Сбера, ради избавления от которого и была набрана толпа Сбертеха. С эффективностью работы этой толпы пока все грустно.>>Да нет, от части отдельных систем не получится избавиться принципиально.Что-то сливают, да.  Но далеко не все в принципе можно слить. Например систему логистики странно сливать с системой бух.учета и  с  системой клиентского обслуживания. Отдельно будет стоять система HR самого банка. Отдельно система руководства проектами.   А, отдельно будет система документооорота и согласования. И может быть не одна.Вот навскидку сразу 6 совершенно разных систем. По факту их намного больше. <<Не образно. Есть стандарт KPI отказоустойчивости систем. Он точно есть у всех крупных компаний >>И в сбере он тоже есть. я не училась в МИРЭА <<Руководство устраивает ))) а клиентов можно не спрашивать )))>>Наблюдается массовый отток клиентов сбербанка?если нет, то о чем речь? Клиент голосует ногами.Для меня текущие удобства сбера перевешивают сбои раз в 3 месяца, часть из которых я даже и не замечаю.Вот когда  несколько лет назад несколько мобильных операторов в течение целого дня не работали, это было жесть.