Вы отнюдь не одиноки. Как консультант я работаю сейчас с ДИТ одного из банков. Там абсолютно такая же ситуация. До этого я работал с ВТБ ... Как правило это типовая проблема для многих организаций с собственным многочисленным подразделением разработчиков и множеством разрабатываемого ПО (но есть исключения!). И она имеет "2 стороны медали", как бизнесовую, так и собственно ИТ-шную:
1. Отсутствие заинтересованности со стороны бизнеса в эффективности ИТ. ИТ воспринимается как сервисное подразделение наравне с хозяйственными службами... и как затратная часть а не как инвестиционная.
2. Множество бизнес-заказчиков высокого ранга, которые сыпят доработки "как из рога изобилия", понимая, что деньги пойдут не из бюджетов их подразделений, а ИТ все это будет делать "за ту же зарплату". Как правило до 30% этих доработок можно было и вовсе не делать :-), если правильно организовать бизнес-процесс (но "мощности ИТ" уже были загружены этой работой).
3. Невысокая заинтересованность в конечном результате. Зачастую сложно найти ответственного за доработку/разработку в бизнес-подразделении. И даже когда ответственного назначают он тихо в курилке матерится что "эта программа никому не нужна". Соответственно возникают проблемы при сдаче-приемке такого софта.
4. Собственно со стороны ИТ нет четкого разделения между операционной и проектной деятельностью. Как правило управления проектами нет. В лучшем случае используется MS Project для "календарного планирования задач". Не ведется учет реальных трудозатрат.
5. Никто не контролирует архитектуру. Как системную так и программную (в пределе EA -- ну до этого у нас вообще не доросли :-)). Нет единых стандартов и правил ее описания. Толком никто не проводит анализ влияния изменений (что будет если тут изменим). Описания дизайна системы я вообще не разу не видел :-) ... в лучшем случае реверс-инжениринг сделают по коду, но это слабо проясняет ситуацию, т.к. трассировок на требования нет.
6. Нет единого репозитория требований к ПО. Как правило невозможно или затруднено получение полного перечня требований разного уровня к существующем релизам ПО.
7. Затруднена идентификация конфигураций, в т.ч. из-за отсутствия той же компонентной архитектуры. Слабое или недостаточное планирование релизов.
8. Традиционно системы создаются в архитектурном стиле "клиент-сервер" и представляют из себя в слабоструктурированные образования ("код в стиле спагетти"). Вынос бизнес-логики на уровень хранимых процедур зачастую не улучшает ситуацию, т.к. все равно остается проблематичным проводить анализ влияния.
9. QA ... ну это вообще отдельная тема. Отмечу что часто это даже не стоит во главе угла!!!
10. Нет Product Manager! Т.к. часто сложно идентифицировать собственно продукты :-).

Все это усугубляется "текучкой кадров" ... а knowlеdge management отсутствует как класс. Процедур распространения знаний о системах нет. Отсюда и вечная кадровая проблема, т.к. пытаются найти уже людей с опытом работы с подобной предметной областью - а их не так много как правило.

Есть ли решение? Да .. главное понять в чем проблема и иметь план действий. Если у вас будет неконтролируемый поток изменений и вы не приучите бизнес расставлять приоритеты (вместе с ним) то будет достаточно сложно вообще стабилизировать ситуацию. Кроме этого нужно показать что ИТ считает деньги ... это мощная переговорная позиция с бизнесом, когда у вас все подсчитано :-).
Но в любом случае нужно браться за улучшение процессов и повышение имиджа ИТ в организации. Улучшать процессы можно по-разному ... можно по-классике (часто начинают с конфигуправления и управления изменениями, а потом идут к требованиям и далее к архитектуре), можно брать за основу модель CMMI (при этом не обязательно сертифицироваться). ISO 9000 как показывает практика в отечественных условиях как-то выхолащивается ... и посему не слишком эффективна. Либо делать по-другому, например использовать Agile методологию Scrum тот же ... но это отдельная тема :-).
Если надумаете улучшать процессы - обращайтесь :-), обсудим, подумаем, предложим решения ... и реализуем :-).