Alexsalog
Вот где тут косяк? В пользователе или постановки задачи типа: "автоматизировать варку борща на украинском хуторе". Ну то есть - подразумевается попытка автоматизировать неавтоматизируемое или прилепить программу там где её наличие только усугубляет положение.

"Косяк" - не в одной конкретной причине, а, как правило, в целом комплеска взаимосвязанных моральных, организационных и технических причин.
Очень кратко на примере автоматизации бухгалтерии.
1 У будущих пользователей, впервые сталкивающихся c компьютеризацией их работы, как правило, складывается неверное понимание возможностей программы, т. е. порождается иллюзия -нажал кнопочку и программа сама все сделает.
Потом начинается прозрение.
Выясняется, что для получения сводных и балансовых отчетов надо предварительно ввести итоговые (накопительные) суммы по всем контрагентам. Вопрос- кто это будет делать и за какие дополнительные деньги? Если обязать делать бесплатно в качестве дополннения к основной работе - получаем скрытый бойкот.
Постоянно надо вести и обновлять нормативные справочники. Опять же - кто это будет делать и за какие дополнительные деньги?

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

3 Система должна четко демонстировать свои преимущества. Если она автоматизирует, пусть и частые, но мелкие операции (типа выписки платежных докуметов, которые и в ручном или полуавтоматическом режиме выполняются достаточно просто), она не будет сильно востребована.
Система должна быть нацелена, в первую очередь, на автоматизацию длительных и трудоемких процессов - например, месячный отчет о расчетах с контрагентами (порядка 10 листов формата А3). Есди она умеет это делать и заменяет многодневный труд нескольких человек - будет востребована. А вводить данные можно и в Exele (если так хочется).

4 И, наконец, главное. Хорошая система должна иметь два режима работы - официальный, предназначенный для выдачи всяких отчетов, справок и т. п. для органов статистики, налоговых структур и прочих мытарей, и неофициальный, предназначенный для информирования руководства о реальном положении дел.

iscrafm ЮВ
а в чем все таки косяк?

Чтобы поставить точный диагноз, нужно обследованин больного.
Система не будет востребована, если:
- не оправдывает ожиданий (автоматизирует не то или неудобна в эксплуатации);
- люди по каким-то причинам морально и психологически не заинтересованы в ней (раньше, например, для стимулирования применяли 10% к окладу за знание иностранного языка).

Alexsalog... Возникает желание обосновать НЕЭФФЕКТИВНОСТЬ (тут на форуме очень плотно поднимали тему эффективности, а я вот значит за НЕЭФФЕКТИВНОСТЬ взялся...) отдельных направлений. Желание сказать: давайте будем проще здесь и здесь. И не только сказать но и показать наглядно, обосновать именно, что втискивание тут и тут в прокрустово ложе автоматизации принесет столько же вреда сколько и пользы и мы останемся в минусе с временем программера потраченным "не на то".
Но подходить с таким - страшновато. Начнут подозревать в лени и отсутствии энтузиазма.

"Подходить страшновато" потому, что нет убедительных доводов.
Так откуда им взяться?
Дело в том, что в большинстве нормативных документов по разработке технических заданий (ТЗ) отсутствует пункт "Цели создания системы" (а в тех ГОСТах, где он присутствет (например, в военных ГОСТах) он умышленно или неумышленно трансформируется в "Назначение системы" (а это, имхо, совершенно разные требования).
Пример.
Министерство путей сообщения (ныне РЖД) решает cоздать автоматизированую систему по продаже и бронированию ж/д билетов. В назначении расписываются функциональные требования к системе (что должна делать). На разработу системы тратятся большие деньги: разработка специального ПО, закупка лицензионного ПО, техники, спецоборудования, дополнительный штат сотрудников для эксплуатации системы, затраты на расходные материалы и т. п.
При этом ни протяженность дорог, ни количество пассажиромест, НИ КОЛИЧЕСТВО ПРОДАВАЕМЫХ БИЛЕТОВ не увеличивается.
Вопрос: в чем цель создания подобной системы? (только не надо приводить здесь коммунистический лозунг "все для блага человека, все во имя человека").
Так вот, когда явно сформулирована цель создания системы - а это, в конечном итоге, имхо, обязательно должен быть экономический показатель, то легко решаются остальные вопросы.
Вы анализируете ТЗ и оцениваете, насколько каждое функциональное требование (назначение)
соответствует достижению поставленной цели. И тут выясняется, что есть требования, без выполнения которых система в принципе не обеспечит нужной цели, есть те, которые мало влияют на достижение цели, но потребуют значительных затрат (и которые можно не автоматизировать или автоматизировать частично), есть вообще требования типа "бантик с боку" и т. п.
Сделав такой анализ, вы получите (с точки зрения достижения цели) список обязательных требований, дополнительных, вспомогательных, чисто сервисных, эргономических и т. п.
С полученными результатами уже можно что-то доказывать и убеждать.

И к заголовку темы: "Пределы автоматизации".
Есть фундаментальный закон:
"Всякая система достигает совершенства перед своим крахом".