Intelligent Enterprise: Какие причины сделали необходимым старт проекта по внедрению ERP-системы?
Михаил Зак: Если говорить о побудительных причинах нашего движения к корпоративной информационной системе, то мы здесь абсолютно не оригинальны: только в интегрированной единой информационной среде, обладающей высоким уровнем актуальности и оперативности, мы можем чувствовать ресурсы, прогнозировать будущее, вырабатывать и принимать объективные и взвешенные управленческие решения. Необходимость и желание совершенствовать созданную систему управления через повышение интеграции, оперативности, достоверности и прозрачности информации стали посылом и привели нас к пониманию идей ERP-системы, а в конечном итоге и к решению об открытии проекта по внедрению R/3.
Надо отметить, что еще задолго до начала проекта с начала 90-х годов мы начали моделировать бизнес-процессы предприятия. Возможности методологии SADT и соответствующие программные средства позволили нам создать к началу внедрения ERP-системы довольно значительный репозитарий моделей "как есть" и "как должно быть". Мы сделали бизнес-моделирование стандартом проектирования информационных систем и научили функциональные службы читать модели. Последнее обстоятельство немаловажно, поскольку именно бизнес-моделирование позволяет информационщикам и функциональным службам говорить о процессах на одном языке и одинаково их понимать.
Цели и задачи проекта были сформулированы в уставе проекта следующим образом: "Создание интегрированной и прозрачной информационной среды для принятия стратегических и оперативных управленческих решений для всех уровней менеджмента, в том числе:
- переход на позаказный метод планирования и учета;
- полная автоматизация бухгалтерского учета до баланса и форм внешней отчетности;
- совершенствование системы планирования и учета затрат".
В устав первой очереди проекта мы включили следующие модули системы R/3: планирование и управление производством (PP), контроллинг (CO), финансы и бухучет (FI), управление материальными потоками (MM) и сбыт (SD). Выбор был обусловлен целями и задачами, которые мы ставили перед проектом, желанием "закольцевать" в системе доходы и расходы и таким образом выйти на финансовый результат, желанием сделать более прозрачной и объективной себестоимость и рентабельность продукции, получить поле для оперативных решений, посыл для своевременного анализа и корректировки бизнес-процессов компании.
Весь остальной функционал сегодня находится за рамками системы, в унаследованных задачах. Вопросы учета основных средств, управления проектами, управления качеством, учета труда и заработной платы, технического обслуживания и ремонта оборудования, управления персоналом и целый ряд других комплексов мы отнесли ко вторым, третьим и будущим этапам перевода в систему. Интеграция данных сегодня осуществляется через обмен между системой R/3 и унаследованными системами.
Как было организовано управление проектом внедрения ERP-системы?
Во главе проекта стоят совет директоров компании и правление. Директора по направлениям назначены приказом кураторами соответствующих модулей. Они вместе с руководителями модулей сформировали состав исполнительного совета. В состав исполнительного совета вошли руководители всех модулей с заместителями. Приказом по компании был сформирован проектный офис. В приказе была оговорена организационная структура, ответственность и персональное наполнение структурных единиц. Основой проектного офиса стали пять модулей системы R/3, решение о внедрении которых было записано в уставе первой очереди проекта.
По каким же критериям отбирались специалисты в проектный офис? Прежде всего это знание соответствующей предметной области, способность описать процесс, анализировать его, предлагать и отстаивать новые модели. Такие люди на предприятии, как правило, заметны. Вопрос в том, что как раз их трудно вырвать из производственных процессов. Определяли всё значимость проекта и поставленные цели.
Мы понимали, что для успешного результата важны не только знания и опыт, но и воля, власть. Поэтому руководителями внедрения ведущих модулей на предпроектной, проектной и продуктивной фазах стали ведущие специалисты и директора по направлениям. Так, внедрение модуля "Планирование и управление производством" возглавил и полтора года проработал в нем директор производства. Внедрение модуля сбыта возглавил директор по маркетингу и сбыту, финансового модуля - заместитель главного бухгалтера. Внедрением модуля контроллинга управлял заместитель начальника экономического отдела. На внедрение модуля управления материальными потоками была утверждена кандидатура одного из ведущих специалистов-бухгалтеров. На вторых ролях в модулях работали в качестве заместителей постановщики задач отдела информационной службы, которые курируют соответствующие направления и вошли в состав инициативной группы проекта на предпроектной фазе. Таким образом, во главе модуля везде стоял топ-менеджер, а заместителем был информационщик. Это сочетание было призвано обеспечить проект властью, знаниями процессов, заинтересованностью в автоматизации и ответственностью за процессы, с одной стороны, а с другой - знаниями в области информационных технологий, интегрированностью подхода, навыками обращения с компьютерной техникой и навигации в программных средствах. Сейчас мы понимаем, что в основном этот подход себя оправдал.
В результате численность сотрудников модулей на этапе старта была такова:
- управление производством и основные данные - 9 человек;
- управление материальными потоками - 5 человек;
- сбыт - 3 человека;
- финансовая бухгалтерия и контроллинг - 4 человека.
Весьма важная сторона проекта - группа технической поддержки, или базисный
модуль. Это специалисты по системному программированию и программисты. Численность
к моменту старта составляла 7 человек - соответственно 3 и 4 человека.
В структуре проекта обозначена еще одна группа - контроля качества. Ее задача
- контроль интегрированности, качества и сроков выполнения работ, проверка обеспечения
и соблюдения стандартов, процедур и принципов проекта. Мы не стали укомплектовывать
ее отдельными специалистами, эти функции легли на специалистов модулей и руководителей.
В качестве методологии внедрения проекта системы R/3 нами была выбрана методология ASAP. Мы практически точно выдерживали и стараемся выдерживать пять основных принципов этой методологии: подготовка проекта, концептуальный проект, реализация, последние приготовления и ввод в продуктив. В значительной степени мы реализовали рекомендации ASAP в части кадровой политики проектного офиса.
Как вы подходили к выбору консультантов по внедрению? Какую тактику работы с поставщиками ИТ-услуг вы использовали?
Консалтинг и обучение команды проектного офиса - это два важнейших вопроса организации процесса внедрения ERP-системы. Они определяющим образом влияют на сроки и качество внедрения. Именно поэтому мы считали необходимым тщательно оценить довольно разнообразный рынок услуг по консалтингу и обучению, прежде чем внедрять систему R/3. Первым и главным критерием отбора консалтинговой компании стал реальный опыт внедрения на известных проектах. Здесь нам важно было найти консультантов, имевших опыт внедрения проекта с участием модуля "Планирование и управление производством" в машиностроении. В качестве второго критерия мы определили непосредственное глубокое знание продукта.
Мы использовали на проекте так называемый "точечный" консалтинг. Суть его в том, что основной объем методологической проработки, настройки и внедрения ложится на проектный офис. Задача же консультантов - научить проектный офис навигации в системе, показать ее возможности, подсказать модели процессов, реализация которых возможна в системе, участвовать в разборе нештатных ситуаций. "Сверхзадача" консалтинга - избавить проектную группу от необходимости обращаться к консультантам, воспитание самостоятельных навыков и умений.
К обучению мы, по сути, подошли с теми же критериями, считая, что учиться необходимо у тех, кто реально делал успешные проекты и сам детально знает программный продукт. Нам удалось реализовать такие схемы консалтинга и обучения вместе со специалистами SAP Сonsult.
Оправдал ли себя такой подход? Думаю, да. Полтора года из чуть более двух с половиной лет продуктивной фазы проекта мы работаем без консультантов. Всегда ли мы были довольны уровнем консалтинга и обучения? В целом - да, мы высоко оцениваем уровень квалификации и опыт специалистов SAP Сonsult. Но иногда, когда дело касалось ранее нигде не внедренных функциональностей, возникали вопросы, которые тем не менее нам удавалось разрешить совместными усилиями. Такая же проблема - отсутствие курсов по новым функциональностям. Для нас это оказалось серьезным осложнением, поскольку наше внедрение было построено на глубоком внедрении модуля "Планирование и управление производством". Внедрение этого модуля в таком объеме на момент старта не проводилось в машиностроительной отрасли, поэтому многие проблемы нам пришлось разрешать и удалось разрешить совместными усилиями.
В какие временные рамки уложились работы по проекту?
Датой начала проекта мы считаем 15 августа 2000 года - дату образования проектного офиса и определения зон компетенции и ответственности всех специалистов и руководителей. К началу проекта был практически определен объем первой очереди проекта и его дальние перспективы. Перед проектным офисом встала задача анализа моделей процессов первого этапа, создания моделей "Как должно быть", проведения там, где это требовалось, реинжиниринга процессов и настройки системы. Параллельно велись обучение проектного офиса, приобретение необходимого оборудования, изменение схемы мотивации персонала.
Концептуальный проект - сборник документов по проекту, то есть проектных решений, методологий и протоколов. По сути, это сборник моделей процессов "Как должно быть" и настроек в системе для продуктивного старта. Он был сформирован в основном к 1 июня 2001 года. С этого времени начались реальные настройки в системе, формирование основных данных системы, первичное тестирование отдельных функциональностей, проверка интегрированности процессов. Эти работы в целом мы завершили к 1 октября 2001 года. Еще два месяца были запланированы на окончательное тестирование и закачку данных в систему.
Практически настроечный период продолжался для нас менее полутора лет. В этом периоде детально тестировались процессы и данные, формировались инструкции и стандарты предприятия. Особое место необходимо было отвести обучению пользователей, многие из которых начали обучение работе в системе с обучения основам компьютерной грамотности.
Процесс настройки серьезно осложнился тем, что с 1 января 2002 года вводился
новый План счетов бухгалтерского учета. В связи с этим требовались глубокий
анализ хозяйственных операций, принятие новых стандартов и схем отражения операций
в бухучете и в системе R/3. Это потребовало дополнительных методических проработок,
дополнительных настроек и обучения работников бухгалтерии. Продуктивный старт
системы состоялся 1 января 2002 года.
Как вы принимали решение о переходе в продуктив. Ннасколько нам известно,с
первого раза система не "пошла"...
Здесь следует сказать о критериях оценки результатов работы ERP-системы. Прежде всего надо иметь в виду, что со стартом, как правило, вступает в действие новая кодировка нормативно-справочных данных, которая в редких случаях повторяет принципы кодировки унаследованной системы.
Далее внедряются десятки и сотни новых методологий и методик в процессах. Сама попытка даже в рамках одного отчетного месяца доказать достоверность внедряемой системы, как-либо сравнивая итоги работы "старой" информационной системы с итогами работы "новой", может быть настолько трудоемкой, что растянется на месяцы. Кроме того, следует объективно и критически взглянуть на основные данные и методологии "старой" системы. Если проанализировать их модели, то становятся совершенно очевидны неактуальность и недостоверность "старой" системы.
Отсюда вывод: бесполезно сравнивать результаты обеих систем, поскольку придется доказать достоверность каждой, и при этом трудоемкость доказательства значительно превысит разумные возможности. Имеет смысл потратить эти силы на качественный анализ результата внедрения, понять, что не сработало, а затем предпринять корректирующие воздействия.
Одним из критериев оценки итогов января 2002 года мы выбрали уровень фактической себестоимости и рентабельности продукции. В системе в ходе настройки были реализованы проектные решения, которые предусматривали кардинальные изменения схемы сбора затрат. Если говорить коротко, суть этих проектных решений состоит в повышении достоверности и глубины учета затрат на основе пооперационного позаказного планирования и учета, введения детальной иерархии мест возникновения затрат (МВЗ), максимально возможного ухода от котлового метода учета и реализации средствами системы положенных в основу каждой статьи продуманных методик. Все это потребовало качественно нового и методически проработанного подхода к организации основных данных системы.
Анализ итогов работы в системе за январь - первый месяц продуктива - как раз и убедил нас в том, что качество основных данных, с которым мы подошли к старту, критически повлияло на результат и недостаточно для продолжения работы. Нам не хватило времени, чтобы стопроцентно проверить в тестовых прогонах системы на предпродуктивной фазе полноту, достоверность и интегрированность данных.
Кроме того, на итоги работы месяца серьезно повлияли массовые ошибки персонала на рабочих местах системы практически во всех функциональных направлениях. Сформированных у людей навыков оказалось недостаточно.
Совместно с консультантами мы приняли тяжелое для себя решение - считать старт производственного модуля системы фальстартом. Обратной дороги к идее параллельного ведения задач и расчетов не было - на это просто не оставалось сил. Надо было срочно перенастроить систему на работу без производственного модуля, в течение полугода провести дополнительную ревизию и коррекцию основных данных и стартовать производственный модуль вновь со второго полугодия 2002 года.
Было ли это решение верным? Сейчас мы уже думаем, что нет. Количество "горячих" проблем, связанных со стартом, когда необходимо оперативно решать вопросы, упущенные в методиках, отстаивать принятые решения, исправлять ошибки персонала, проводить донастройки системы, анализ и коррекцию данных, растет в начале внедрения по экспоненте. Психологически мы, очевидно, просто были не готовы перенести это в январе, но перенесли точно такой же стресс внедрения после старта в июле. В целом же именно от психологической готовности и "выученности" команды проекта и пользователей, от их мобильности и нацеленности на результат, на идею в высокой степени зависит успех реинжиниринга процессов и внедрения ERP-системы.
С какими еще проблемами вы столкнулись?
Прежде всего необходимо отметить важность качественной проработки тех проектных решений, которые вкладываются в систему. Нам не всегда и не везде до конца удалось продумать модели процессов "Как должно быть". Недостаточное качество моделирования неизменно сказывалось и продолжает сказываться сейчас на качестве работы системы, заставляет уже в реальном времени корректировать данные и настройки системы. Это сложный процесс со многими взаимосвязями.
Каковы же причины некачественного моделирования? Во-первых, это короткие сроки внедрения при захвате в проект очень большой функциональности. Оценить реально эти сроки действительно сложно при планировании. Тем не менее необходимо как можно жестче очерчивать рамки проекта. Во-вторых, необходимо достаточное количество специалистов, способных к методической и аналитической работе в функциональных службах и в проектном офисе. Этот момент серьезно влияет на качество и сроки проектных решений.
Одна из серьезных проблем - консерватизм и сопротивление персонала внедрению.
И то и другое действительно осложняет ход проекта, привнося в него серьезное напряжение. Это реальный фактор риска, существующий как непосредственно на рабочих местах, так и у управленцев всех уровней. Сопротивление проекту, приверженность к старым методам работы способны практически уничтожить эффект от всех усилий по проекту. Просто приказами здесь не решить ничего.
Что же реально можно сделать? Мы пытаемся подходить массированно и разнообразно. Это и презентации для руководителей и специалистов с целью демонстрации возможностей системы. Это технико-экономические советы и совещания, где обсуждаются те или иные модели процессов и принимаются проектные решения. Это стремление к максимально четкому планированию работ по внедрению, постоянное, иногда многократное, но терпеливое обучение и убеждение. Это готовность к реальной помощи и консультациям со стороны проектного офиса в любой момент дня и ночи, это, наконец, личные беседы и т. д. С другой стороны, работает система ответственности за исполнение решений и контроль исполнения документов.
Кроме того, к важнейшим проблемам я бы отнес проблему мотивации персонала на внедрение. Эту тему можно обсуждать как по отношению к разработчикам системы, так и к пользователям. Для пользователей мы приняли концепцию освоения нового качества, нового наполнения рабочего места. Другими словами, рабочее место, оснащенное той или иной функциональностью системы R/3, может занимать только специалист, освоивший приемы работы с системой. Такой подход серьезно мотивировал работников на обучение системе и освоение. Дополнительных оплат в период внедрения для персонала не вводилось.
Что касается разработчиков, то практически 100% состава офиса разработчиков были переведены на контрактную оплату труда. Это оправданно, поскольку для нас предпроектная, проектная и начало продуктивной фазы - 2,5-3 года работы по 12-14 часов для многих практически без полноценных выходных и отпуска. Кроме того, это значительный рост квалификации, связанный с пониманием и освоением нового менеджмента.
Еще одна проблема, связанная с мотивацией. Это переманивание специалистов-разработчиков на другие предприятия, внедряющие систему R/3. Более всего у нас это коснулось программистов. Сегодня уже три наших специалиста работают на проектах в Москве, при этом воспитание нового специалиста требует достаточно времени и значительных средств. Об этой проблеме нужно думать уже на начальных стадиях проекта.
Хотя, наверное, в таком проекте нет маловажных вопросов. Что угодно может свести на нет ваши усилия - выбор консультанта и модели взаимоотношений с ним, проектный офис и аппаратная часть, сопротивление менеджмента и пользователей, а также многое другое.
