Дмитрий Шехватов, директор по развитию бизнеса компании «Корпоративные и финансовые системы»

Главный принцип: все, что может быть использовано, должно быть использовано. Этой практики стараются придерживаться все серьезные консалтинговые компании, занимающиеся внедрением ERP-систем. К выбрасыванию старого нужно относиться с большой осторожностью. Нередко решение, входящее в новую ERP-систему, оказывается не совсем подходящим. И это неудивительно — многие программы на предприятии разрабатывались «под себя», с учетом нюансов, которые порой не поддерживает ни одна ERP-система. Вопрос — как быть?

Каждый случай должен быть отдельно проанализирован. Параметры анализа:

а) сложность и уникальность пакета;

б) возможность автономной работы.

Во многих случаях интеграция нескольких систем в одну концептуально осмыслена лишь на уровне представления сводных данных из частных систем в общую. Специализированные программы при таком подходе выступают средством сбора информации. Однако не все так просто. Дело в том, что данные специализированной системы обычно представляют собой законченный результат для принятия управленческого решения (иначе эту программу невозможно использовать автономно) и не предполагают преобразование или анализ в другой системе. Пример — сотруднику (например, обслуживающему персоналу, выполняющему текущий ремонт) необходимы данные:

— из системы оповещения о возникшей неисправности;

— из ERP-системы, сгенерировавшей в ответ наряд-заказ на выполнение работ;

— чертеж устройства, подлежащего ремонту;

— монтажная схема устройства;

— доступ к форме ввода данных о завершении ремонтных работ;

— статистика по наработке на отказ, отклонению от параметров, усталостным показателям и т. п. из системы качества.

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

Важно отметить, что ERP-системы — это событийные системы. Интеграция внутри них означает, что событие, возникшее в одном блоке (регистрация счета-фактуры, отпуск материалов в производство и т. п.), приводит к изменению в других (изменение баланса предприятия, пересчет складских запасов, изменение кредиторской задолженности и т. п.). Подобные взаимодействия и есть реальная интеграция. Именно эта интегрированность дает наибольший эффект от использования ERP-пакетов. Непонимание этих принципов и стоящих за ними управленческих концепций обычно порождает фантазии вроде 100-процентной интеграции ERP-систем с CAD/CAM или АСУ ТП.

Если наследуемое ПО препятствует реализации этих принципов, то от него следует отказываться в первую очередь. Иначе серьезного эффекта от ERP-системы получено не будет. Например, существующая в организации программа управления складом поддерживает также элементы бухгалтерского учета. В этом случае от нее необходимо как можно скорее отказываться (либо отключить бухгалтерский контур, если это возможно).

Приведу несколько примеров. У одного из наших клиентов использовалась внедренная программа для бухучета и собственная программа логистики и управления контрактами. После детального анализа был сделан вывод о том, что программу логистики следует сохранить и интегрировать с IFS Applications, а от внедренной программы для бухучета следует отказаться, заменив его на финансовую подсистему IFS Financials, что и было сделано.

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

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

Нужно заметить, что внедрение ERP-системы и без того дает большую нагрузку на предприятие. Если можно некоторое время использовать старые программы, пусть они работают. Параллельный режим оправдан только на период перехода от одной системы к другой, в условиях интенсивной работы с компьютерной системой. Наилучший вариант — не допускать параллельной работы, а сделать резкий переход к новой системе.

При попроцессном внедрении такой подход возможен и оправдан.

Алексей Втулкин, руководитель службы ИТ компании «АЗР Автомобиль — звезда Руси»

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

Одним из таких представлений может явиться, так сказать, «надстройка» над уже имеющимися системами. Возможными целями могут быть: создание механизмов обмена данными между разрозненными системами, объединение данных для удобства работы с ними или создание и хранение каких-либо промежуточных итогов. Противоположный подход предполагает полный отказ от существующих систем в пользу новой.

Область нашей деятельности — это продажа автомобилей «Мерседес-Бенц», запасных частей и аксессуаров, и ремонт автомобилей этой марки. Являясь официальным дилером с момента основания, мы были вынуждены поддерживать корпоративные стандарты обработки и обмена информацией с нашим основным поставщиком. Объем только справочной информации, например каталогов запасных частей и ремонтных работ, составляет десятки тысяч записей. Информация о работе магазина запасных частей и аксессуаров, склада и сервиса обрабатывается системой, созданной для нас одной из отечественных фирм в 1995 г., система бухгалтерского учета была поставлена другой отечественной фирмой. Также существует набор программ, созданный силами сотрудников нашего отдела ИТ и призванный восполнить пробелы в обработке и представлении данных, образованные отсутствием определенной функциональности в основных системах. Эти три группы систем абсолютно не связаны между собой. И в нашем случае явилось возможным приступить к объединению и частичной замене большей части имеющегося комплекса ПО на единственную систему IFS. Замена касается всего, за исключением корпоративных систем. С последними, с помощью ИТ-подразделения представительства «Даймлер-Крайслер» в России, был создан программный интерфейс, позволяющий получать данные из корпоративных электронных каталогов в IFS.

Проблемы переходного периода в нашем случае возникли, прежде всего, при переопределении связей: внедрение всех приобретенных модулей системы IFS сразу показалось нам неразумным ввиду очевидной сложности процесса и возможно критичного для деятельности фирмы количества проблем. Поэтому в первую очередь был запущен блок бухгалтерского учета и управления финансами, полностью заменивший нашу старую систему бухгалтерского учета. Для встраивания его в наши бизнес-процессы потребовалось переопределить направление и состав информационных потоков. На очереди внедрение модулей работы с запасными частями и управления сервисным обслуживанием. По своей сути весь механизм внедрения можно рассматривать как полную замену одной из существующих систем на первом этапе и дальнейшее, последовательное подключение остальных модулей заменяющей системы. Состав же подключаемых модулей определяется связями звеньев автоматизируемого процесса. Если связи слабы — конечно, можно жить с несколькими системами одновременно сколько угодно. Но в общем случае, если нужна оперативность и интеграция, в мире давно существует общее решение — системы класса ERP. Проблемы здесь, на мой взгляд, всего две — понять, что в действительности хочешь, и каким составом все это можно реализовать. А решение этих проблем всегда частное.

<<2