Больше ответов - меньше вопросов.
На днях пришел мне вопрос относительно вот этого поста, который написал без малого год назад в котором меня попросили описать более подробно - почему с проектами происходят такие вот неприятные вещи. Ответ на этот вопрос достачно простой и он никаким образом не связан с технической стороной дела. Нет, конечно когда будет плохое техническое исполнение хорошего плана, то фиаско гарантированно, но речь идет несколько о другом - когда начинают оправдывать неудачу проекта только ее технической реализацией.
Для того, что бы был более понятен механизм "провала операции" ее надо рассмотреть во всех деталях. Итак, предположим, некая компания Z решила что она жить не может без какой-нибудь супер-навороченной системы планирования ресурсами (управления предприятем) или, на худой конец, системы документооборота. С чего обычно начинается проект? Как правило с подбора непосредственно системы, которую планируют внедрять на предприятии и с подрядчиков, которые могут выполнить работы в полном объеме и еще взять систему на гарантийную поддержку.
На этом этапе, как правило, осознанная работа заканчивается и начинается хождение по заколдованному кругу - "потратили деньги -> поставили систему -> она вроде бы работает, но от нее нет никакого толку -> сделайте что-нибудь". Сделать, обычно, уже ничего нельзя и не потому что системы или люди работающие на предприятии какие-то неправильные, а потому что вводные условия были изначально неверными.
Теперь постараемся разобраться почему так происходит и как этого избежать. Начать надо с того, что очень часто происходит внедрение ради самого внедрения и забывается главная цель - зачем, собственно говоря, нужно внедрение любой системы на любом предприятии. Ответить на этот вопрос означает ответить и, самое главное, понять - почему проваливаются проекты по внедрению сложных систем. Почему-то считается, что основная работа по внедрению - чисто техническая (поставить оборудование, настроить софт, обучить людей), но забывается, что главной задачей стоящей перед внедренцами является составление четкого плана прохождения информационных потоков внутри предприятия и подстройка системы под уже существующие потоки.
Именно от того, насколько четко и ясно представлен подобный "информационный план предприятия" напрямую зависит скорость и корректность внедрения любой системы. Если же этого не сделать на начальном этапе, то немного позже произойдет классическая ситуация - начнутся попытки (или прямое изменение) работы предприятия под внедряемую (внедренную) систему, а не усиление и упрощение уже существующего взаимодействия между разными структурными подразделениями. К чему это приводит в итоге? Приводит это к тому, что ресурсы предприятия начинают тратиться на подковерные игры между отделами в которых каждый будет стремиться спихнуть ответственность на других и компании, понятно дело, от таких раскладов ничего хорошего ждать не надо. На внедренцев, понятное дело, начинают смотреть как на "врагов рода человеческого", которых надо расстрелять в ближайшей подворотне (по крайней мере в фантазиях работников).
Теперь самое интересное - понимание того, как работают внутренние информационные потоки. Вот здесь-то обычно и выясняется, что вообще мало кто на предприятии понимает общий производственный цикл и может внятно объяснить, что "здесь-вот-так-вот, а здесь - вот-так-вот". Если таких людей нет - получается как в примере с судами штата Калифорния, если есть - то выходит некая "лоскутная" автоматизация разных подразделений, а затем "допиливание напильником" (еще не самый худший вариант) и интеграция в общую рабочую среду.
Вывод - чем больше ответов на начальном этапе работы над проектом - тем меньше вопросов к самому проекту перед его сдачей в эксплуатацию и в ходе последующей поддержки.