Единство и борьба противоположностей. Бухгалтерские системы и внедрение систем ERP

Условно программные комплексы можно разделить на две группы: со встроенным языком программирования и с разветвленной системой настроек. В первом случае доработка под конечного пользователя или задачу осуществляется посредством перепрограммирования (допрограммирования) комплекса; во втором – выбором различных опций и вводом фиксированных значений в схеме настройки.

На самом деле это искусственное разделение, так как большинство систем управления предприятием имеет встроенный язык программирования, посредством которого рисуются формы ввода, создаются отчеты, разрабатываются те же самые схемы настройки и т. д. А системы, которые называют программируемыми, все равно имеют конечные пользовательские конфигурации, которые в свою очередь можно менять с помощью настроек и т. д.

Основное отличие двух видов, пожалуй, состоит в том, какую функциональность можно смоделировать путем настроек (не программируя) и насколько удачно будет реализован этот процесс.

Наиболее распространенная в мире система управления предприятием R3 (более половины всех инсталляций) имеет встроенный язык программирования ABAP. Однако на его платформе реализованы настолько универсальные модули (конфигурации) финансов, логистики, производства и т. д., что программирование на ABAP для решения бизнес-задач считается дурным тоном. У специалистов, работающих с R3, есть такое наблюдение: если полез в язык, значит, не разобрался в настройках. И анекдот. Вопрос программиста: «Что делать, если нужной настройки нет в системе?» Ответ: «Искать дальше».

Основные типовые конфигурации тиражных программ, например, программ системы «1С» подходят для многих предприятий, а для других эти программы могут быть относительно быстро доработаны (созданием специальных конфигураций), поэтому и стоят относительно недорого. Конечные же разработки для конкретной сферы, скажем, той же «1С-Рарус») имеют массу настроек, «заточены» под конкретный бизнес и цену имеют соответствующую.

Если конечный пользователь имеет силы и желание, он может купить себе программный «конструктор» или «полуфабрикат», а потом строить и дорабатывать его под собственные нужды самому или с помощниками. Что получится в результате – это уже область ответственности участников проекта доработки. Причем не только исполнителя, но и заказчика. Впрочем, бывает, что только такой вариант устраивает и нужен заказчику и, значит, экономически оправдан.

В малом бизнесе не принято платить за обследование предприятия, постановку учета и т. п. Интуитивное общение заказчика и разработчика на «языке жестов» в режиме реального времени зачастую может принести воистину ядовитые всходы. Появившееся в результате такого альянса «дитя» (изделие) уже не будет являться типовой конфигурацией, поддерживаемой основным разработчиком, и, вероятно, потеряет возможность корректного автоматического обновления версий. Так что ко всем расходам еще добавятся затраты на сопровождение оригинальной конфигурации. Хорошо, если «отцом ребенка» окажется официальный «полномочный представитель» поставщика (разработчика) основной программы, в противном случае возможны проблемы.

Вроде бы недорогая система оказывается не лучшей для конкретного применения и в результате не столь уж дешевой. Конечная совокупная стоимость рабочего места в результате может достигать тех же 150 – 500 долларов, что и в сложных «настроечных» системах для среднего бизнеса. Тех же, кто думает, что даже для небольшой фирмы за 400 – 700 долларов можно осуществить комплексную автоматизацию (постановка, доработка, сопровождение, обновление), ждет горькое разочарование.
И чтобы потом не расстраиваться, не обижаться и не ругать «лукавых» поставщиков, лучше сразу реально смотреть на вещи.