Ничто не совершенно в этом мире: чем дольше мы задерживаем внедрение, тем больше у нас шансов увидеть недостатки в своей собственной работе.
Ничто не совершенно в этом мире: чем дольше мы задерживаем внедрение, тем больше у нас шансов увидеть недостатки в своей собственной работе. С другой стороны, существуют факторы, которые могут послужить достаточным основанием для отсрочки ввода системы в эксплуатацию. Один из них — хаос в данных старых систем, который говорит о том, что их чистка не была проведена. Вторым существенным фактором является то, что пользователи не изучили новые процессы предприятия и не освоили ERP-систему в объеме своих ежедневных обязанностей. Последний фактор — интерфейсы, не доказавшие своей работоспособности. Практика показывает, что наличие этих трех обстоятельств может «утопить» проект в первые же дни существования ERP-системы на предприятии.
Предположим, что интеграционный тест 2б, о котором говорилось в предыдущей статье, завершен. Его последний день является кульминационным: на основе итогов теста либо принимается решение о вводе ERP-системы в эксплуатацию, либо переносятся сроки окончания проекта.
Продление проекта нежелательно по нескольким причинам: во-первых, неизбежно увеличивается стоимость внедрения; во-вторых, теряется сосредоточенность участников — люди не могут находиться в напряжении бесконечно долго; и наконец, продлевается стрессовый период самого предприятия — лучшие работники оторваны от основной деятельности. В каждом проекте будут существовать открытые вопросы и проблемы.
При принятии решения о вводе системы в эксплуатацию целесообразно руководствоваться правилом «80:20», которое утверждает, что 20% усилий достаточно, чтобы достичь 80% результата. На достижение 100% желаемого придется потратить оставшиеся 80% усилий. 20% недочетов могут быть устранены и после внедрения.
При положительном решении производятся следующие действия:
- конфигурация и программы копируются из тестовой в «боевую» ERP-систему;
- объявляется о замораживании разработок всех программ и конфигураций;
- дается официальный старт переносу данных.
Впереди остается финишная прямая, на которой командам нужно лишь повторить отрепетированное ранее.
В базовой компании накоплен большой опыт внедрений SAP R/3 — только за последний год были проведены пять полномасштабных проектов, каждый из которых охватывал как минимум модули управления дистрибуцией, управления запасами и производственный модуль. Были задержки — на месяц, два. Но по всем проектам был достигнут желаемый результат. Образно говоря, внедрения поставлены на поток. С конвейера по реализации внедрений с частотой пять раз в год и длительностью цикла в шесть месяцев сходит готовый продукт, изготовленный по технологии тиражирования модели. Как и ожидается при поточном производстве, продукция получается в значительной мере стандартной. Достоинством стандартизации является оптимизация процесса обслуживания системы. Действительно, внутренний консультант SAP R/3, который знаком с функциональностью модели, способен осуществлять поддержку любого подразделения компании, независимо от того, где оно расположено территориально. Это в свою очередь открывает возможности дальнейшего удешевления обслуживания. Наметившаяся во всем мире тенденция выноса центров компетенции в страны третьего мира не обошла и базовую компанию — значительная часть поддержки по горячей линии, написания программ и конфигурирования была передана в Индию, где заработная плата, как известно, ниже европейской.
Этап 8. Автоматизированный перенос данных в «боевую» ERP-систему
На этот этап отведено три недели (вместо обычных двух) с тем, чтобы иметь запас времени для реагирования на непредвиденные проблемы, возникающие при переносе данных. Практика показывает, что недоделки неизбежно «всплывают», и именно в этот критический период.
Базовая структура этапа не отличается от аналогичного этапа для интеграционных тестов 2а и 2б. Внедрение призвано повторить уже отработанную процедуру переноса данных.
Для этого этапа характерно то, что одновременно работают два программных комплекса: унаследованные системы и ERP. С момента копирования основных данных в ERP-систему начинается период двойного обслуживания. Смысл двойного обслуживания состоит в репликации изменений основных данных старых систем в ERP-системе. Создание новых кодов материалов, изменение атрибутов поставщиков и клиентов, ввод новых техпроцессов, корректировка структуры продуктов — вот лишь некоторые из возможных действий, которые должны быть отражены сразу в двух системах, и желательно — одновременно. Данный подход гарантирует, что:
- в течение трех недель предприятие имеет возможность работать со старыми системами;
- загрузка в ERP-систему по незавершенным операциям не столкнется с проблемой отсутствия основных данных;
- вывод старых систем из эксплуатации не повлечет за собой потерю информации.
Двойное обслуживание осуществляется конечными пользователями и продолжается до момента ввода ERP-системы в эксплуатацию.
Загрузка данных по незавершенным операциям (заказы на закупку, заказы клиентов, производственные заказы, остатки на складе) невозможна при их непрерывном изменении. При планировании финальной стадии переноса данных надо исходить из того, что операции в старых системах придется заморозить примерно на четыре дня, два из которых — суббота и воскресенье. Мероприятия данного этапа рекомендуется приурочить к закрытию очередного учетного периода, с проведением инвентаризации непосредственно перед переносом данных о складских запасах. Для того чтобы уложиться в четырехдневный срок, командам проекта придется работать круглосуточно.
Производственные подразделения тоже должны подготовиться к вводу ERP-системы в эксплуатацию. Вот несколько рекомендаций на этот счет, приводимых базовой компанией.
- В течение первых трех дней недели переноса данных по операциям отгрузите максимальное количество заказов клиентов. Распечатайте отгрузочную документацию на четверг и пятницу с тем, чтобы продолжать физическую отгрузку во время отсутствия системы.
- Попытайтесь завершить производственную программу недели в трехдневный срок. Выполнение производственных заказов физически может не прерываться, но необходимо учесть, что данные по выполненным операциям надо будет сохранить в виде рукописных документов и провести уже в ERP-системе.
- Проинформируйте клиентов, что во второй половине недели они не будут получать счета; поставщикам сообщите, что оплата производиться не будет.
- Попросите поставщиков произвести доставку товаров только в первой половине недели.
Эти и другие мероприятия позволят минимизировать влияние вынужденного бездействия программных систем на внутреннюю и внешнюю деловую активность предприятия.
Сообщите заранее партнерам о замене программных систем предприятия и вытекающих отсюда последствиях. Например, существенными факторами для них может стать изменение вида заказа на закупку, корректировка формы счетов, выставляемых клиентам, изменение кодировки материалов.
После того как все данные по текущим операциям загружены в ERP-систему и тщательно проверены, необходимо переходить к запуску регулярных пакетных процессов. Это последний шаг автоматизированного переноса данных. Суть его состоит во включении всех новых, только что загруженных продуктовых линий предприятия (в том числе новых поставщиков, клиентов) в стандартные автоматические процессы обработки данных предприятия. Примерами пакетных процессов могут являться: планирование потребностей материалов (MRP), калькуляция недостающего количества по производственным заказам, подтверждение заказов клиентов, распечатка цеховой документации, автоматическое выставление счетов по отгруженным заказам.
Осенью прошлого года очередной проект внедрения SAP R/3 в подразделении базовой компании в предместье Парижа, «Сержи-Понтуаз», вступил именно в эту фазу — с 14 по 17 октября осуществлялся перенос данных по незавершенным операциям. Командам удалось частично синхронизировать перенос с производственным процессом — в четверг (14-го) и пятницу (15-го) предприятие продолжало отгрузку, но прием новых заказов был остановлен. Операции по массовому копированию данных из старой системы в новую начались в пятницу вечером и продолжались круглосуточно, вплоть до утра 18 октября. За два дня и три ночи в SAP R/3 были загружены четыре тысячи заказов на закупку, двенадцать тысяч заказов клиентов, пятнадцать тысяч записей по остаткам на складе, а также прогноз продаж. Приостановленные пакетные процессы предприятия были запущены снова, и в 9 утра в понедельник система была открыта для конечных пользователей.
Этап 9. Ввод в эксплуатацию и поддержка
Общая длительность этапа — 4 недели.
С понедельника после почти шести месяцев усилий команд начинается эксплуатация системы. Проект внедрения вступает в завершающую фазу — поддержки после внедрения.
Две недели поддержки на объектах предприятия
Первые две недели наиболее тяжелые для всех команд и для предприятия в целом. Люди вдруг обнаруживают, что перед ними больше нет тех до боли знакомых экранов старой системы, где они могли работать почти автоматически, не задумываясь при нажатии клавиш. Вместо этого есть ERP-система, для изучения которой у них было не так много времени. Начинается интенсивное освоение системы пользователями методом «учебы в процессе».
Команды проекта, до сих пор работавшие в одной комнате, расходятся по объектам и отделам, поближе к конечным пользователям. Их задача — слившись с массами, помочь раскрутиться маховику ERP-системы.
Команда бизнес-экспертов возвращается в подразделения, на свои рабочие места, но прежние обязанности пока на себя не берет. Они помогают закрывать бреши в процессах, проводят дополнительное обучение пользователей непосредственно на рабочем месте.
Члены команды аналитиков ERP-системы следуют за партнерами из команды бизнес-экспертов на объекты и включаются в процесс обучения. На ближайшие две недели их место — за спинами конечных пользователей. Помимо этого команда аналитиков системы оперативно решает вопросы, относящиеся к программному обеспечению и конфигурации системы.
Ежедневно проводятся совещания, на которых представители команд аналитиков системы, бизнес-экспертов, системной поддержки и руководитель проекта обмениваются информацией об успехах освоения системы, оперативно решают проблемы.
Двухнедельный этап поддержки после ввода системы в эксплуатацию в уже упоминавшемся проекте в «Сержи-Понтуаз» только что завершился. Он оказался стрессовым не только для бизнеса предприятия, но и для команд внедрения. Было не очень приятно осознавать, что в который раз наступили на «одни и те же грабли»: пользователи снова задавали базовые вопросы, а новый интерфейс по передаче заказов из SAP R/3 в систему управления производством не работал целый день, блокировав всю логистику предприятия.
Поучителен опыт начальника отдела планирования одной из продуктовых линий предприятия. Вопреки требованиям модели системы, он решил отказаться от включения «своих» материальных позиций в общие пакетные процессы. Мотивация простая: «Надо сначала посмотреть, как это работает». Что ж, «посмотреть» и даже «почувствовать» удалось в полной мере: к концу первой недели отдел планирования оказался «завален» ручной работой по открытию заказов на закупку, а количество рекомендаций продолжало увеличиваться с каждым запуском MRP. Все вернулось на «круги своя», когда автоматическое преобразование рекомендаций системы в заказы на закупку было включено и для этой «уникальной» продуктовой линии. Ее руководитель согласился, что проще контролировать результат работы системы, чем заниматься рутинной работой по выдаче заказов.
Две недели удаленной поддержки
В идеале после двух недель работы предприятия с ERP-системой ситуация стабилизируется. Команда аналитиков системы может возвращаться в свои домашние офисы и осуществлять поддержку по телефону, подключаясь к системе в режиме удаленного доступа. Команда бизнес-экспертов возвращается к своим прежним обязанностям в отделах.
По окончании четырех недель поддержки проект внедрения ERP-системы заканчивается. Команда аналитиков системы расформировывается. Сотрудники отдела ERP-систем предприятия возвращаются к своим обязанностям по сопровождению внедренных систем.
Вздох с облегчением
Проект закончен, и можно проанализировать пройденный путь. Кратко перечислим то, что способствовало успеху проекта.
Во-первых, модель. Готовность команд «сражаться до последнего» за ее целостность, используя в первую очередь уже имеющиеся в модели функциональности, позволила не увязнуть в исследовании бесконечного множества модулей ERP-системы, сосредоточиться на внедрении, уложиться в сжатые сроки.
Во-вторых, активные, квалифицированные участники команд проекта. Сочетание их разноплановых знаний (как системных, так и тех, что касаются бизнес-процессов предприятия) позволило оперативно решать задачи проекта.
В-третьих, сосредоточение всех усилий на проекте, когда участники команд были полностью освобождены от своих текущих производственных обязанностей.
В-четвертых, главная ответственность за проект была передана тому, кто наиболее заинтересован в его результатах — команде бизнес-экспертов.
В-пятых, жесткий контроль границ и содержания проекта позволил не допустить его продления. Строгий шестимесячный график внедрения способствовал максимальной концентрации участников на проекте.
В-шестых, наличие четкой и проверенной методологии ведения проекта.
В этой связи стоит выделить еще один фактор успеха — организацию. Он, с одной стороны, очевиден, с другой — часто не находит должного внимания у тех, кто этим обязан заниматься. Если не синхронизировать работу всех участников проекта, то не поможет и отличная методология. И хотя в этой области базовой компании далеко до совершенства, вызывают уважение те усилия, которые она прилагает для улучшения процессов управления. В области ведения проектов акцент делается на четком соблюдении методологии, исчерпывающем информировании участников и других заинтересованных лиц, а также на заблаговременной подготовке каждого последующего этапа. В рамках методологии внедрения руководство четко определяет задачи промежуточных фаз проекта и контролирует их выполнение.
Особое место среди факторов успеха занимает мотивация участников. Уже не раз было замечено, что участники команд работают самоотверженно по 10-12 часов в день, на время отодвинув свою личную жизнь на второй план. Что движет ими?
Сколько существует людей, столько есть и причин их заинтересованности. Одни считают, что внедрение ERP-системы в дальнейшем облегчит их работу. Другие видят в проекте возможность отвлечься от своих рутинных обязанностей. Кто-то решил, что это поможет его карьере: он станет ключевым пользователем и будет более заметен в коллективе. Некоторые просто любят все новое, любят ставить перед собой новые задачи.
Получение знаний и опыта — безусловный мотивирующий фактор. Многочисленные работы по дизайну и адаптации процессов предприятия требуют разобраться в деятельности не только своего подразделения, но и всех смежных с ним. Полученные знания передового программного продукта и опыт внедрения несомненно повышают цену участников проекта на рынке труда.
Комфортные условия работы и достойное финансовое вознаграждение способствуют росту заинтересованности участников команд. Но одного этого недостаточно. Официальное признание руководством предприятия абсолютной важности результатов проекта для деятельности всей компании порождает ощущение собственной значимости, осмысленности приложенных усилий, заставляет работать на идею, оставляя материальные выгоды на втором плане.
В базовой компании используется интересный способ поощрения — «общественные мероприятия». Один раз в месяц в вечернее время компания приглашает участников проекта сделать что-то вместе. Это может быть игра в боулинг, картинг, познавательная экскурсия или коллективный ужин. В неформальной обстановке люди не только отдыхают от напряженного ритма жизни в офисе, но и, общаясь на отвлеченные темы, ближе знакомятся друг с другом. Такие мероприятия позволяют растопить лед отчуждения, способствуют формированию дружеских отношений в рабочем коллективе.
Политика мотивации в совокупности с очевидными выгодами участия в проекте позволяет создать коллектив, ориентированный на достижение цели проекта.
Метод тиражирования модели делает возможным внедрение ERP-систем на предприятиях практически любого масштаба. Методология, приведенная в настоящей статье, позволяет осуществлять проекты таких внедрений за шесть месяцев. Разработав модель ERP-системы в ходе первого проекта внедрения, обеспечив необходимые условия, компания может проводить дальнейшие проекты быстро и надежно. Модель — естественный выбор тех предприятий, которые хотят использовать при внедрениях свой собственный опыт, экономя тем самым силы и средства.
Игорь Шершов — независимый эксперт, shershov@mail.ru
Методология тиражирования модели позволяет поставить на поток внедрение ERP-систем, завершая каждый проект в шестимесячный срок. Она включает в себя несколько этапов — предпроектную подготовку, официальное открытие проекта, обучение команд и интеграционные тесты 1, 2а и 2б, которые были рассмотрены в журнале «Директор информационной службы» № 6 и № 12 за 2004 год.
Если предприятие следует изложенной выше методологии, то по окончании интеграционного теста 2б основной комплекс работ проекта окажется выполненным — команды отработают бизнес-процессы, процедуры переноса данных из старых систем в ERP-систему, будет проведена огромная работа по чистке данных старых систем, фактически подготовлена инфраструктура предприятия, идет полным ходом обучение пользователей.
Главная предпосылка успеха при использовании данного подхода — наличие модели, представляющей собой совокупность стандартных бизнес-процессов предприятия, реализованных в ERP-системе. Эта модель позволяет сконцентрироваться на внедрении, не теряя времени на исследование бесконечного множества функциональностей ERP-системы.
Нельзя также забывать о принципах формирования команд проектов. Группировка бизнес-экспертов и аналитиков ERP-системы в команды по направлениям — склад, закупки, продажи, производство — позволяют добиться максимально эффективной работы.
Для иллюстрации методологии тиражирования модели в качестве примеров используются фрагменты истории внедрения SAP R/3 в транснациональной корпорации, упоминаемой в статье под именем «базовая компания».
Организационная структура проекта
Команды бизнес-экспертов и аналитиков ERP-системы составляют костяк и основную рабочую силу проекта.
В команду бизнес-экспертов входят представители производственных подразделений. Для них характерно отличное знание бизнес-процессов и программных комплексов предприятия. Главная задача этой команды состоит в разработке новых бизнес-процессов предприятия с учетом возможностей модели ERP-системы.
Команда аналитиков ERP-системы включает в себя опытных специалистов из числа сотрудников ИТ-отдела предприятия, привлеченных консультантов и программистов. Их главной задачей в процессе внедрения является инсталляция и конфигурация ERP-системы, присоединенных программных комплексов и интерфейсов к ним, а после внедрения — поддержка пользователей системы.
В целях более эффективного проведения разработок и быстрого обмена иформацией, сотрудники родственных направлений обеих команд объединены в рабочие группы по направлениям: закупки, продажи, финансы, производство и планирование, склад.