Светлому образу Генетического мусора посвящается.

Что мы имеем в настоящее время?
1. ERP. Дорогие, но неплохо масштабируемые программные комплексы. Как правило, требуют использования промышленных СУБД и хороших серверов. Как правило, не поддерживают offline-обмн, требуют постоянного коннекта. Активно используют тонкие клиенты. Есть отраслевые решения. К сожалению, в российских реалиях практически не могут быть внедрены без кастомизации, порой очень затратной (хотя отдельные модули (Закупка, Логистика, CRM) можно внедрять практически без изменений .
Основные минусы: высокие первоначальные затраты, необходимость кастомизации, плохая поддержка вендорами местного законодательства, много затратных, но неуспешных проектов (в т.ч. по причинам, не зависящим ни от ИС, ни от Исполнителя), затруднена модификация базового функционала.

2. 1С. Широко разрекламированный продукт. Низкая пороговая стоимость. Большое количество спецов и литературы. Неплохая поддержка. Большое количество партнеров. Развитые средства разработки и модификации. Хорошо подходит для итеративного внедрения. Поддерживает распределенные БД. Де-факто промышленный стандарт в области РСБУ.
Основные минусы: удобная среда разработки сочетается с недоразвитостью функциональных решений. Требует постоянной доработки напильником. Отвратительная масштабируемость при числе юзеров > 50. Высокие аппаратные требования. Практически отсутствуют апробированные отраслевые решения (то что есть - самопал с одного-двух проектов). Высокая стоимость специалистов.

3. Прочие российские тиражные системы. Их много. Большинство ушло в тень, не выдержав конкуренции с 1С. Самые крупные (Парус, Галактика, Альфа) заняли оборону в нишевых секторах рынка. Почти все системы хорошо поддерживают российские законодательство и практику применения. Большое число успешных проектов.
Основные недостатки: малое количество партнеров, отсутствие финансовых ресурсов для конкуренции, зависимость от одной немногочисленной группы разработчиков.

4. Самописные заказные решения на базе ЯВУ и наиболее распространенных СУБД. Наиболее полно решают проблемы Заказчика. Зачастую великолепно масштабируются даже на слабых серверах.

Основные недостатки: как правило, плохая документируемость проекта, риск зависимости от команды разработчиков, ограниченная функциональность, не позволяющая без дополнительной разработки быстро подключать новые модули. Зависимость от уровня методистов Заказчика.


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

Аксиомы:
1) Любая система нуждается в доработке.
2) Любая система должна иметь возможность быстро и как можно менее затратно наращивать функциональность путем обновления на новые версии, полученные от производителя системы.
3) Любое предприятие стремится сократить совокупную стоимость владения системой, складывающуюся из стоимости первоначальных лицензий, стоимости доработки, стоимости пусконаладочных работ, стоимости поддержки, стоимости специалистов, стоимости аппаратно-технических средств.
4) Любая система должна максимально эффективно интегрироваться с другими ИС, образуя единое информационное поле предприятия.

Эти аксиомы образуют клубок противоречий.
Как его разрешить? По какому пути следует двигаться?

iscrafm HryuckinnenТеоретическая база у отечественных разработчиков ERP и учетных систем очень хреновая.


абсолютно оторванное от реалий видение. Ничего не соответствует действительности.

А я как раз соглашусь. Hryuckinnen прав на 100% (огромное спасибо ему за пост). Я в свое время имел доступ к исследованиям по матмоделированию закупок и уровня запасов в условиях плановой экономики СССР. MRP-II в сравнении с этим - детский лепет. Ничего подобного на уровне нынешних софтописателей не применяется. Много Вы знаете современных российских школ (а не отдельных экономистов), занимающихся проблемами диспетчеризации и оптимизации производства, логистики в плане разработки математического аппарата? Я знаю только примеры в области управления финансами (биржа, инвестиции).

Да уж, системы Банк-Клиент - классический пример вакханалии и бардака в отдельно взятой отрасли. Почему государство не наведет порядок - не понимаю.
Может, дело в голове? Ведь применяются же на Западе стандарты электронного обмена инвойсами, ордерами? А у нас кроме 1С-овского CommerceML ничего в голову не приходит. Но это чаще всего опять на уровне 1С-1С.

OA UserПроблема решилась проще - сравнением затрат времени операционистки и времени на разработку :).
Я немного о другом хотел сказать, унификация (в том числе обмена данными между сервисами) становится востребованной, когда дает бизнесу конкурентные преимущества.

Можно и сверху надавить. Причем объяснить, что делается это для блага самих организаций. Например, налоговая теперь не будет требовать бумажные копии всех накладных за два последних года, а ограничится выгрузкой из ИС на CD и сопроводительным реестром, заверенным печатью и подписями .