Методология тиражирования модели позволяет поставить на поток внедрение ERP-систем, завершая каждое внедрение в шестимесячный срок.

Методология тиражирования модели позволяет поставить на поток внедрение ERP-систем, завершая каждое внедрение в шестимесячный срок. Она включает в себя несколько этапов, первые четыре из которых (предпроектная подготовка, официальное открытие проекта, обучение команд и интеграционный тест 1) были рассмотрены в журнале «Директор информационной службы», №6 за 2004 год. Автор считает необходимым отметить, что главная предпосылка успеха здесь — наличие модели, представляющей собой совокупность стандартных бизнес-процессов предприятия, реализованных в ERP-системе. Всюду в качестве примеров используются фрагменты истории внедрения SAR R/3 в транснациональной корпорации, упоминаемой в статье под именем «базовая компания».

Этап 5а. Интеграционный тест 2а

Общая длительность этого этапа — восемь недель. В его рамках выделяется фаза подготовки к тестированию и собственно тестирование.

Подготовка к тестированию и автоматизированный перенос данных

Здесь целесообразно остановиться на понятии переноса данных. На момент принятия решения о начале внедрения ERP-системы предприятие обычно уже работает с программным комплексом. Модули комплекса разработаны силами самого предприятия либо приобретены извне. Часто это конгломерат программ с низкой степенью интеграции. Имеет место неполнота и неструктурированность информации. Реквизиты системы не контролируются, что дает пользователям полную свободу их заполнения и порождает разнобой в кодировках, активно применяется Excel для хранения специфических данных.

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

В напряженном графике проекта внедрения на подготовку тестирования, как правило, отводится шесть недель. Далее приведены приоритеты, расставленные базовой компанией на данном этапе.

Цели и задачи

Главная задача — подготовка трех необходимых составляющих для первого полномасштабного интеграционного теста процессов предприятия.

Первый компонент — это тестовая система, состоящая из ERP-системы и присоединенного программного комплекса, сопряженного с ней интерфейсами.

Второй — данные для тестирования. Реальные производственные данные старых систем в полном объеме должны быть загружены в ERP-систему, что осуществляется посредством автоматизированного переноса данных.

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

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

Работы этапа

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

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

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

Интересная ситуация сложилась в базовой компании в связи с требованием ERP-системы SAP R/3 классифицировать товары по месту их преимущественной отгрузки клиентам. Поскольку R/3 дает возможность указать только одно значение, то его фиксация для каждой материальной позиции, по сути, привязывала клиентов к одному центру дистрибуции. Все заказы клиентов, регистрируемые в системе, по умолчанию текли в фиксированное место отгрузки. Несмотря на то, что данное ограничение системы в точности повторяло перспективную стратегию компании в Европе — каждый продукт хранится только на одном складе, ни один из трех автоматизировавшихся на тот момент центров дистрибуции не желал терять бизнес. Развернулась скрытая политическая борьба за долю в доходах компании. К счастью, здравый смысл взял верх — бизнес получило то подразделение, которое имело наибольший объем поставок по данному продукту в последние 12 месяцев. Таким образом, элементарное требование SAP R/3 о группировке товаров по месту их преимущественной отгрузки способствовало оптимизации логистики компании.

Составление карт переноса данных. Подготовка к переносу данных из старых систем — наиболее длительная и кропотливая работа в ERP-проекте. Начало этой деятельности было положено на этапе подготовки к интеграционному тесту 1 (его описание в предыдущей статье о методе). Зафиксированные в картах правила соответствия реквизитов систем быстро устаревают и должны повторно анализироваться по мере накопления знаний о будущих бизнес-процессах предприятия. Состояние готовности карт с учетом допущений должно быть достигнуто к моменту начала переноса данных в тестовую систему интеграционного теста 2а.

Таблица содержит возможный вариант карт переноса данных по заказам на закупку. Для записей используется файл MS-Excel. Здесь:

  • общие правила — краткое описание границ и содержания переноса;
  • наименование реквизита, техническое название — привязка к реквизитам ERP-системы;
  • формат данных, смещение/длина — описывает структуру промежуточного файла, в который выгружаются данные из старых систем для их последующей загрузки. Файл обычно имеет текстовый формат;
  • таблица/номер экрана/наименование реквизита — привязка к экранам старых систем;
  • правило преобразования данных — содержит детальное описание правил преобразования реквизитов одной системы в другую. При слишком длинном описании оно выносится в отдельный файл, а в карте дается ссылка.

Определение стратегии переноса данных. Известно два метода переноса — ручной и автоматический (программный). Для каждого вида данных выбирается наиболее подходящий, исходя из объема данных, выделенного времени, сложности алгоритмов преобразования и наличия ресурсов — программистов, операторов.

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

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

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

Инструментарий автоматизированного переноса данных включает в себя:

а) программы выгрузки данных из старых систем;

б) программы реформатирования данных (чтоб «подогнать» их под читаемый ERP-системой формат);

в) функциональные модули самой ERP-системы, предназначенные для загрузки данных;

г) средства верификации качества переноса данных.

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

Средства верификации данных после переноса могут быть простыми, как Excel, или немного посложнее — Access. Этот инструментарий позволяет выполнить массовую проверку выгрузки/загрузки данных. Нельзя, конечно, списывать со счетов и ручной метод. На практике используются оба подхода.

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

Методология проверки состоит в сравнении записей старых систем с соответствующими данными в ERP-системе, минуя программы выгрузки/загрузки.

Практический совет: два файла-выборки лучше, чем один! Первый файл содержит все активные записи старых систем, подлежащие переносу. Второй — все исключенные записи. Желательно указать также причины исключения каждой из них. Таким образом, оба файла вместе объединят все записи старой системы, что гарантирует прозрачность переноса данных.

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

Объем и сложность работ, связанных с присоединением специфических программных модулей предприятия к ERP-системе, нельзя недооценивать. Как показывает практика, любой интерфейс несет в себе риск задержки выполнения проекта. Проверено, что интерфейс обязательно перестанет работать в первый же день после ввода системы в эксплуатацию, несмотря на то что на его написание и тестирование была потрачена уйма времени. С этой точки зрения интерфейс — великое зло. Его необходимо избегать при любой возможности!

Интерфейсы становятся неизбежными, если предприятие выберет метод частичной замены старых систем на новую. Так произошло и в одном из недавних проектов базовой компании. Руководство предпочло разбить полную автоматизацию предприятия на несколько разделенных во времени проектов. На первом этапе SAP R/3 внедрялось для финансового отдела и отдела продаж. Кроме того, в SAP выносилось планирование и отгрузка конечной продукции. Производственный модуль, в силу его сложности, решили оставить на потом. Для связи SAP со старой системой — системой управления производством — в план работ внесли также три интерфейса: передача изменений основных данных, передача потребностей в конечной продукции и формальная приемка товаров в SAP.

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

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

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

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

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

Во-первых, у совещания должен быть модератор — человек, который следит, чтоб участники придерживались темы, не «растекались мыслью по древу», укладывались в отведенное время. Модератор — это не обязательно самый знающий, опытный участник. Его задача — дирижировать, направлять к цели, создавать деловую атмосферу, подытоживать и обобщать.

Во-вторых, обязательно наличие плана совещания. План должен быть ориентирован на решение вынесенных на обсуждение проблем.

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

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

Ожидаемый результат этапа подготовки к тестированию

Цель этапа подготовки к интеграционному тесту 2а считается достигнутой, если комплекс программ — тестовая ERP-система, интерфейсы и присоединенный программный комплекс — отлажен на одиночных примерах и признан готовым к массовому тестированию, сценарии проверки бизнес-процессов предприятия в основном написаны, а совокупный результат загрузки данных составляет 60%, в том числе по каждому виду данных — 90%. Большой объем обработанных данных позволит убедиться в надежности программ их выгрузки.

Собственно тестирование

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

Цели и задачи

Цель тестирования — доказать, что с помощью ERP-системы предприятие сможет выполнять обычные бизнес-процессы.

Работы этапа

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

Если нежелательное все же случится и выяснится, что один из критических для предприятия процессов был упущен из рассмотрения на предыдущих этапах, то возможно возникновение риска задержки проекта. Несмотря на то что проект находится лишь в его середине, ресурсы могут быть уже связаны в других, плановых мероприятиях и бросить их на внеплановые может оказаться невозможным. Данную проблему реально было бы предвосхитить на этапе подготовки проекта — при составлении документа о границах и содержании проекта (project scope) — либо при предыдущем тестировании, когда должны были проверяться критические процессы предприятия. Дилемму — задержать проект, расширить его границы и содержание либо найти дополнительные ресурсы — решать руководящему комитету.

Отдельным видом работ при данном тестировании считается проверка стандартных форм и отчетов на предмет их соответствия потребностям предприятия.

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

Ожидаемый результат

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

Допускается, что финальные бизнес-процессы предприятия будут незначительно отличаться от тех, которые были оттестированы в интеграционном тесте 2а.

Этап 5б. Интеграционный тест 2б

Общая длительность этого этапа — шесть недель. В его рамках выделяется фаза подготовки к тестированию и собственно тестирование.

Данный этап подобен интеграционному тесту 2а. Ниже приведены его характерные особенности.

Подготовка к тестированию и автоматизированный перенос данных

Цели и задачи

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

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

Два года назад один из проектов внедрения SAP R/3 должен был автоматизировать плановую группу, состоявшую из десяти человек. Участникам команд было очевидно, что после ввода системы в эксплуатацию работы хватит лишь на троих. В коллективе ходили слухи о сокращении штата, но, видимо, в силу щекотливости вопроса, руководство до самого конца проекта не давало однозначного ответа. Поскольку ждать решения было равносильно задержке тестирования, то за основу была принята цифра три, и оба интеграционных теста прошли с учетом распределения заказов и обслуживаемых материальных позиций именно на три человека.

Время показало справедливость «допущения» команд проекта — после внедрения SAP R/3 количество работников уменьшилось на семь человек. И в этом нет ничего удивительного — получение максимального экономического эффекта от внедрения — это нормальное желание руководства.

Работы этапа

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

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

Подготовка инфраструктуры. Характерным видом деятельности данного этапа является подготовка инфраструктуры предприятия под ERP-систему: закупаются принтеры, компьютеры, команда системной поддержки конфигурирует и подсоединяет их к сети предприятия.

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

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

Ожидаемый результат этапа подготовки к тестированию

Цель субэтапа считается достигнутой, если совокупный результат загрузки данных составляет 95%, что составляет порядка 99% по каждому виду основных данных и текущим операциям.

Кроме этого, предполагается, что команды активно поработали и на 99% завершили чистку и унификацию данных.

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

Собственно тестирование

По своей структуре данный субэтап подобен интеграционному тесту 2а. Он является вторым и последним в проекте комплексным интеграционным тестом. Отрабатываются не только основные процессы, но и очень специализированные с максимальным количеством вариаций. Принимается во внимание вся цепочка — от планирования и регистрации заказа клиента до его отгрузки, получения денег и составления бухгалтерской отчетности. Многочисленные участники теста пытаются «озадачить» систему, испытать ее на прочность. Только если она «выдержит», тест считается успешным.

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

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

Этап 6. Обучение конечных пользователей

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

Обучение начинается со второй недели интеграционного теста 2б и проводится исключительно командой бизнес-экспертов.

Этап 7. Интеграционный тест 3

Длительность — три дня. Проводится на второй неделе интеграционного теста 2б одновременно с ним.

В задачу теста входит проверка инфраструктуры предприятия на предмет готовности ЛВС, принтеров и компьютеров пользователей к вводу ERP-системы в эксплуатацию. Помимо этого контролируется наличие паролей и прав доступа пользователей.

Отдых на «вершине» перед финишной прямой

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

Фактически все готово к последнему броску — сформированы новые бизнес-процессы, а интеграционные тесты 1, 2а и 2б показали, что ERP-система их адекватно отражает. Готовы главные силы — конечные пользователи, а интеграционный тест 3 закрыл последний пробел — инфраструктура предприятия способна выдержать ожидаемый подъем активности.

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

Игорь Шершов — независимый эксперт, shershov@mail.ru

Портрет «базовой компании»

Базовая компания — это транснациональная корпорация, имеющая производственные предприятия и торговые представительства во многих странах мира. По данным на 2003 год, оборот компании составил 10,4 млрд. долл. США; количество сотрудников достигло 80 тыс. человек. Продуктовый ряд компании включает 320 тыс. наименований. ТНК лидирует в производстве пассивных электронных компонентов: электронные реле, предохранители, провода, компьютерные кабели, оптоволоконные провода и соединители, терминаторы, разнообразные коннекторы... Продукцию компании закупают фирмы, работающие в таких секторах индустрии, как аэрокосмический, автомобилестроение, компьютерная и бытовая электроника, телекоммуникации, электроэнергетика.

Около пяти лет назад руководством компании было принято стратегическое решение о выборе SAP R/3 в качестве стандартного корпоративного решения для автоматизации деятельности всей цепи поставок. Был взят курс на поэтапную замену старых разрозненных систем отдельных предприятий на единую SAP R/3.

Подготовка и «тиражирование модели» были признаны наиболее оптимальным методом внедрения SAP R/3. К настоящему моменту в системе работает более 5 тыс. пользователей. Их количество и география внедрений продолжает расширяться.