EFIR.COM.UA

Сравнительный анализ альтернативных вариантов.

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

В этом контексте, для создания корпораций и обеспечения их управляемости на первый взгляд самым простым и беспроигрышным представляется подход «постепенной автоматизации». Суть его заключается в том, что автоматизируются вначале очевидные, самые распространенные операции, например, бухгалтерский учет. Причем для простоты автоматизируется лишь какая-то часть учета – либо по номенклатуре, либо по подразделению. Затем предполагается автоматизация других, так же широко распространенных операций - кадровый учет, складские операции, контроль исполнения поручений и т.п. Сторонники этого подхода убеждены, что таким путем они быстрее получат отдачу и выйдут на уровень комплексной автоматизации если и не в кратчайший срок, то с меньшими потерями. Но при этом упускается из виду только специалистам понятная проблема – все указанные операции и все не указанные, но очевидно необходимые – все они тесно взаимосвязаны. Но для упрощения, а иначе простоты не получится, взаимосвязями пренебрегают. И тогда для получения комплексности необходимо либо все наработки «выбрасывать» и начинать все сначала, либо нести заведомо большие затраты на сшивание кусков в лоскутное одеяло. К сожалению, коммерческие интересы фирм разработчиков, как правило, толкают именно на этот путь – «говорите, что вам надо и мы сделаем», а понесенные затраты превращаются в доходы разработчика. Иными словами, этот путь опасен тем, что «в трубу вылетают» затраты малыми суммами, но при большой видимой «активности» разработчика.

Второй альтернативный путь основан на интуитивном представлении заказчика, что его проблемы – типичны, и что существуют стандартные методы быстрого их решения. Эти представления также коммерчески выгодны разработчикам, исповедующим правило – «сделаем все, только плати больше». И действительно, специалисты этого направления свое дело знают. Но следует учесть, что стандартных объектов не существует, и решения достигаются ценой очень больших затрат. Например, исповедующие этот путь немецкая SAP, или японско-французская Deloit&Tuche «берут» за комплексность не десятки тысяч, а миллионы долларов. Но дешевле комплексности от стандарта и не достичь.

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

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

Белослюдцев Н.Н.