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

Техника подготовки и проведения основных фаз внедрения будет интересна всем, кто собирается произвести замену унаследованных систем на системы класса ERP

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

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

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

Цель настоящего изложения состоит в том, чтобы показать, как ERP-система может быть внедрена за 6 месяцев. В качестве примера выбраны проекты внедрения ERP-систем в одной из зарубежных компаний (базовая компания – БК), которая вот уже четыре года с успехом их реализует на своих производственных подразделениях.

Создание предпосылок успешного проекта

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

К примеру, предприятие уже выбрало одну из ERP-систем как стандарт автоматизации.

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

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

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

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

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

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

Тиражируемая модель ERP-системы.

Модель рассматривается в двух плоскостях – технической и функциональной.

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

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

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

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

Опыт разработки модели

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

Основы модели, ее базовая конфигурация были сформированы двумя первыми проектами внедрения SAP R/3. Один из них имел цель автоматизировать финансовые потоки. В границы и содержание второго проекта входила вся логистика – закупки, производство, реализация. Внедрения проводились параллельно для двух разных организационных единиц компании, и заняли около двух лет. У проектов не было задачи разработать нечто фундаментальное. Тем не менее, когда речь зашла о последующих внедрениях SAP R/3, появилась идея воспользоваться наработанным в них опытом, конфигурацией и процессами. Группа аналитиков, включившая в себя представителей производственных подразделений, сотрудников ERP-направления отдела ИТ компании и привлеченных консультантов SAP проанализировала результаты предыдущих проектов. Путем слияния конфигураций систем от первых двух проектов внедрения, некоторых доработок и выбора необходимых присоединенных программных комплексов была создана модель ERP-системы компании. Она вобрала в себя специфику деятельности всех входивших на тот момент в состав БК организационных единиц. Все последующие внедрения проходили методом тиражирования модели.

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

Методология внедрения ERP-системы

Рассмотрев основные предпосылки успешного проекта, перейдем к самой методике тиражирования модели. На диаграмме 1 представлена временная последовательность этапов типового проекта.

Этап 1. Предпроектная подготовка

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

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

  1. Вопросы об обюекте внедрения в целом: площадки, продуктовые линиии, количество пользователей, тип производства (дискретное/непрерывное), процессы предприятия (резка, штамповка, покраска, сборка).
  2. Уникальные процессы предприятия.
  3. Характеристика программных систем и комплексов, используемых в настоящий момент.
  4. Список интерфейсов с внешними для обюекта внедрения системами, например EDI с поставщиками и клиентами, интерфейс с корпоративной системой финансового учета и с остающимися не затронутыми внедрением старыми системами предприятия.
  5. Обюем основных данных и данных по незавершенным операциям.
  6. Необходимое обновление персональных компьютеров и сетей предприятия.
  7. Предварительный список сотрудников, которые могут быть вовлечены в проект на постоянной основе.
  8. Другие.

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

В документе перечисляются модули ERP-системы, приесоединенные программные комплексы и интерфейсы к ним, которые в обязательном порядке должны войти в проект. Что не менее важно, также указываются модули, внедрение которых не предусматривается. Документ можно дополнить описанием процессов предприятия, которые войдут либо не войдут в проект. Например, можно указать, что расчеты с поставщиками/клиентами являются его частью, а расчет заработной платы – нет; либо что коммуникация с поставщиками посредством EDI войдет в план мероприятий последующих проектов внедрения и будет исключена из данного.

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

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

Границы и содержание проекта помогают определить состав его участников, а также разработать план и бюджет.

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

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

За рабочим комитетом следуют руководители проекта. Обычно их двое – один от бизнеса, один от отдела ERP-систем предприятия. Их обязанность – управлять внедрением в своей области, координировать усилия команд. Они несут ответственность за успех проекта.

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

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

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

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

Конечные пользователи – это работники на местах. Не вовлечены в проект. Их задача – научиться работать в ERP-системе.

Составление плана и бюджета проекта. Существует мнение, что использование таких средств, как Microsoft Project, создает ненужную сложность в управлении проектом и требует чрезмерных временных затрат. Для внесения изменений в файлы MS Project требуется определенная квалификация, которой большинство участников команд не обладает. Таким образом, поддержание плана в актуальном состоянии ложится целиком на плечи руководителя проекта, что неизбежно отрывает его от главной задачи – руководства. Информация, содержащаяся в плане, оказывается недоступной большинству сотрудников, так как, в отличие от MS Word или Excel, Project не входит в стандартный набор программ, устанавливаемых на компьютерах пользователей.

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

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

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

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

Этап 2. Официальное открытие проекта

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

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

Теперь, когда дорога вперед открыта и пора переходить от слов к делу, остается последний вопрос – как оптимально организовать коммуникацию в проекте? О важности коммуникации при любом внедрении, и не только ERP-систем, написаны книги. Нет необходимости их цитировать. Прописные истины, изложенные там, дополним неким зрительным образом – картинкой идеального общения. Представьте себе... одну большую комнату. Ближе к углам комнаты расположены четыре массива столов, уставленных компьютерами. Вокруг столов плечом к плечу сидят участники команд проекта, сгруппированные по направлениям (закупки, продажи, склад, финансы...). Группы отделяют друг от друга лишь несколько метров. В комнате жарко – и не только от большого количества людей, но и от множества споров, дискуссий и телеконференций, идущих одновременно в разных концах комнаты. Тестируются процессы, разрабатываются концепции, конфигурируется система, пишутся программы, пьется кофе... Если кто-то «уперся» и не знает, что делать (а может, просто неохота думать?), вопрос «выстреливается» в воздух, и можно не сомневаться, что один из коллег-специалистов тут же придет на помощь. Информация как бы витает в воздухе, оседая в головах всех, кто находится в комнате. Если сегодня кого-то нет на месте, а дело стоит, можно позвонить; если таковых несколько, то на помощь приходит телеконференция. А с членами команд, которых нет на месте, можно обменяться электронными сообщениями. После 12 часов в таком «улье», гудит голова, но ощущаешь, что прогресс есть.

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

Этап 3. Обучение команды бизнес-экспертов ERP-системе

Длительность этого этапа – две недели.

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

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

Общая длительность этого этапа – шесть недель: субэтап подготовки к тестированию – четыре недели, собственно тестирование – две недели.

Подготовка к тестированию

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

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

Работы этапа. Большая часть четырех недель месяца должна быть посвящена двум видам деятельности: разработке будущих бизнес-процессов предприятия в ERP-системе и составлению карт переноса данных.

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

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

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

Еще одним видом работ, которые необходимо упомянуть, является чистка данных в старых системах.

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

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

Тестирование

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

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

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

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

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

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

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

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

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

* * *

Формат небольшой журнальной статьи не позволяет представить читателю эту методологию целиком. Окинем взглядом пройденный путь. Что является основой предлагаемого подхода? Это, безусловно, модель. Затем следует обратить внимание на предпосылки успешности проекта. Прежде всего это участие в нем лучших специалистов предприятия, далее важно формирование команды и определение лидера. Необходимо соблюдение правила – бизнес впереди, за ним информационная служба. Также верно должны быть определены границы и содержание проекта и, наконец, необходимо достойное финансирование. По завершении определенных выше этапов ожидается, что знания о проекте выросли, ключевые процессы оттестированы, брешей нет (но только теоретически), данные вычищены, карты сделаны, все проблемы занесены в журнал. Что же дальше? В ближайших публикациях читайте описание других этапов внедрения методом тиражирования модели: интеграционных тестов, точки апогея проекта, переноса данных в «боевую систему». Отдельно будет рассмотрен этап поддержки после внедрения. Пристальное внимание будет уделено методологии подготовки автоматизированного переноса данных из старых систем в ERP-систему.

Игорь Шершов – независимый эксперт. Его вгляды на управление ERP-проектами во многом сформировались в течение четырехлетнего периода работы в БК в Германии, в отделе информационных систем в качестве системного аналитика, консультанта системы SAP R/3. Связаться с автором можно по адресу: shershov@mail.ru


Портрет базовой компании (БК)

По данным на 2003 год, оборот компании составил 10,4 млрд. долл.; количество сотрудников достигло 80 тыс. человек. Продуктовый ряд компании включает 320 тыс. наименований. Компания лидирует в производстве пассивных электронных компонентов: электронные реле, предохранители, провода, компьютерные кабели, оптоволоконные провода соединители, терминаторы, разнообразные коннекторы и др.

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

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

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

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

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


Риск 3

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


Риск 2

Вот еще один подводный камень, о который можно продырявить дно «ковчега» проекта.

Пример из практики БК. Недискретная единица измерения КАТ, катушка, одного из покупных материалов, используемых в производстве 30 наименований полуфабрикатов, была признана подлежащей замене на дискретную единицу М, метр. Эту операцию не провели вовремя. В результате при очередном переносе данных материал был отвергнут ERP-системой, как были отвергнуты и 30 соответствующих структур продукта, около 20 заказов на закупку и множество производственных заказов, в которых данный материал числился как компонент. Несколько таких материалов могут ввергнуть проект в настоящий хаос. Чистые данные, как чистые руки перед едой, – залог здоровья ERP-системы!


Карты переноса данных

Несколько примеров, приведенных ниже, помогут получить представление о процессе составления карт переноса данных.

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

Другой пример. Имеющийся во всех ERP-системах реквизит – «покупной/производимый на предприятии материал» возможно вычислить посредством анализа структур продукта (Bill Of Material, BOM) в старой системе. Соответствующий алгоритм может выглядеть так: если у материала есть компоненты (has BOM), то реквизит = «производимый на предприятии»; если компонентов нет (has no BOM), то реквизит = «покупной».