Организационные проблемы в ИТ проектах

Классический случай провала внедрения ERP-системы.

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

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

И при этом внедрения проваливаются, а ко мне в IM обращается знакомый программист с вопросом "вот я передаю экземпляр соединения с базой данных в dll, а потом когда я выгружаю dll - все падает с исключением. Я пока он него защищаюсь, окружив все try except end". И это ведущий программист у себя на конторе, причем вполне себе вменяемый человек, просто он (и не только он) даже не знает, что есть best practices, про которые можно прочитать и которые можно использовать.

Метод внедрения ИТ (и не только ИТ) систем, используемый в 83% случаев

"Насаждать! Палками пиздить! ©"

Работает. Проверено.

Явно случай для WorseThanFailure

Схема БД:


Характерный пример (формат слегка перекорежен во избежание)
Имя таблицы HR0030207 где HR имя модуля создатели которого решили что им нужна таблица в БД. 003 -уникальный код таблицы в программном модуле HR (хотя некотрые модули пользую "чужие" таблицы без зазрения совести). 02 код компании даные которой там хранятся (код 00 выделенный это самая главная компания данные которой берутся если специфичной для компании таблицы не найдется). 07 - код года за который присутствуют данные (код 00 специальный показывает что это единая для всех годов таблица даннве не поодрахделяются по годам - что специалисты iScala делали в 2000 я сие чудо встретил позже). Назначение таблиц в модуле никак не регламетировано и нигде не документировано . Поля в такой таблице именуются - HR003001, HR003002, HR003003