В условиях кризиса возросли требования к качеству и срокам реализации ERP-проектов. Как правильно организовать проект по внедрению ERP-системы и о каких подводных камнях нужно знать заранее? Этой теме посвящена очередная статья совместного проекта журнала «Эксперт» и корпорации Microsoft «Тюнинг управления»
Внедрять ERP-систему — все равно что делать капремонт в квартире в присутствии хозяев» — так отозвался о сути ERP-проектов исполнительный директор одного машиностроительного предприятия. Стоит пояснить аналогию: «хозяева», то есть руководство компании-заказчика, должны принимать активное участие в ERP-проекте на всем его протяжении. Это главное правило внедрения корпоративной информационной системы класса ERP. Если при капитальном ремонте квартиры есть возможность наблюдать за проектом со стороны, переложив все заботы на прораба, то в случае с ERP это не так. Каким бы квалифицированным ни был подрядчик, какие бы возможности ни предоставляла компьютерная программа, отдалиться от проекта — самая большая (и часто встречающаяся) ошибка, приводящая к неудачам при внедрении. Образно говоря, низкое качество отделки даже прекрасно спроектированного жилья может свести на нет все положительные эмоции.
Что представляет собой внедрение ERP-систем? Если сказать в двух словах, то это изменение схемы ведения бизнеса компании при переходе на новые информационные технологии. Как известно, цель внедрения этих систем — повышение качества управления предприятием. На рабочем месте сотрудника появляется очередная компьютерная программа, куда требуется вносить данные. Эта информация видна другим сотрудникам, которые тоже вводят данные в соответствии со своей сферой ответственности. Действия сотрудников четко регламентированы, а результат работы практически в онлайн-режиме становится доступен линейному менеджменту и высшему руководству. На основании полученной информации принимаются оперативные и стратегические управленческие решения.
Конечно, описанные выше результаты — лишь верхушка айсберга. Чтобы достичь желаемых целей при внедрении ERP, многим сотрудникам придется с головой погрузиться в проект (исключение — внедрение «коробочных» программных продуктов, не требующих консалтинга, сложных настроек и доработок). Своеобразным навигатором, позволяющим шаг за шагом идти к намеченной цели и подводить промежуточные итоги, выступают методологии внедрения, применяемые производителям ERP и их партнерами.
Этапы большого пути
ERP-проект принято разбивать на ряд этапов. Многие производители ориентируются на рекомендации и стандарты PMI — универсального метода проектного руководства, разработанного Project Management Institute, PMI. У разработчиков разных ERP-решений названия фаз (стадий, этапов) проектов различны, но подходы и рекомендации схожи. Так, одним из стандартов при внедрении ERP-решений SAP является методология ASAP, при внедрении продуктов Microsoft Dynamics — методология Microsoft Dynamics Sure Step. Рекомендуемый Microsoft порядок внедрения состоит из шести этапов (диагностика, анализ, дизайн, разработка, развертывание, эксплуатация). В составе ASAP пять фаз — подготовка проекта, концептуальный бизнес-проект, фаза реализации и интеграционного тестирования, заключительная подготовка к продуктивной эксплуатации, наконец, продуктивный запуск и поддержка. При внедрении приложений Oracle используется методология Oracle AIM for Business Flow, которая тоже подразумевает разбивку проекта на пять фаз. Ключевым отличием подхода Oracle в компании называют «использование метода последовательных приближений». В ходе проекта последовательно создаются три прототипа будущей системы, функционально все более и более близких к искомому результату. А реальная система доступна заказчику с самого начала проекта, и можно вживую выдвигать и корректировать требования к ней. Практически это ведет к тому, что освоение системы начинается вместе с еe проектированием, а не после сдачи в эксплуатацию.
Любое внедрение начинается с подготовки проекта — диагностики. На этом этапе, в частности, клиент выбирает платформу для автоматизации и подрядчика . Правильно проведенная диагностика позволяет значительно сэкономить время и средства на следующих этапах проекта. В частности, подробно ознакомившись с возможностями выбранной системы (не только на скриншотах и презентациях, но и увидев реально работающую систему своими глазами), можно сократить длительность этапа анализа бизнес-процессов — одного из ключевых для успешного воплощения проекта.
При реализации ERP-проектов большинство неудач случается из-за человеческого фактора. И потому правильный подход к формированию внедренческой команды — залог успеха. Группа, которой предстоит заниматься внедрением системы (проектный офис), почти всегда формируется из представителей компании-клиента и подрядчика. Клиент обязательно должен быть представлен не только руководителям службы ИТ, но и другим управленцам, включая высшее руководство. Их (скажем, финансового, коммерческого директоров, руководителя отдела сбыта — то есть всех тех, чьи подразделения впоследствии будут работать в ERP-системе, тех, кто будет пользоваться отчетами из системы) целесообразно включить в состав проектной группы как можно раньше. А поскольку многие ERP-проекты внесут серьезные изменения в бизнес-процессы, чему далеко не все будут рады, высшее руководство компании должно поставить ответственным за реализацию всего проекта харизматичного менеджера, пользующегося большим влиянием на предприятии и способным побороть все «не хочу» и «не могу». Другими словами, как признались в одной металлургической компании, «в ERP-проекте всегда должен быть кто-то, кто сумеет взять на себя функцию лающей собаки».
Во всех ERP-проектах обязательно надо позаботиться о мотивации сотрудников. Причем не только участников проектной группы, но и тех, кто будет наиболее активным «на местах». Практика показывает, что даже небольшой премиальный фонд может значительно облегчить процесс внедрения. В противном случае почти наверняка найдутся те, кто станет саботировать проект. В компании «Вагонмаш» подобных противников разбили на две категории — на «активных» и «пассивных»; в компании «Еврохим» — на три: «консерваторы», «маленькие царьки» и «воры» (подробнее о методах борьбы с сопротивлением персонала см. интервью «Сопротивление было везде» [3] и «Главная победа осталась за нами» [4]).
Анализ прежде всего
На этапе анализа выясняют главное: чего ожидают от ИТ-системы ключевые пользователи, то есть руководство среднего и высшего звена. Для этого, в частности, нужно проанализировать способы реализации бизнес-процессов, предлагаемые производителем ERP-системы. К примеру, понять, какова последовательность действий при отгрузке товара со склада готовой продукции: какую информацию нужно иметь перед отгрузкой, что необходимо прописать в документах, в какой момент в процесс включается бухгалтерия. Анализируемые процессы делятся на составные части и описываются — словами или в виде блок-схем. Важнейшая на этом этапе задача — найти расхождения между пожеланиями заказчика и возможностями системы. Проектная группа решает, какие бизнес-процессы лучше сохранить, изменив под них работу программы, а какие изменить, выстроив их по стандартной логике, предлагаемой производителем ERP-системы.
На практике вокруг этой темы часто разворачиваются нешуточные баталии. К примеру, известна масса случаев, когда главные бухгалтеры выступают против изменений — им не нравится, что проводку по финансовым счетам теперь будет осуществлять производственный персонал: например, данные счетов-фактур станут вносить в систему кладовщики. Бухгалтер не хочет менять существующий порядок, когда все бумаги к концу месяца стекаются в бухгалтерию, которая лихорадочно начинает вносить их в программу. То, что это нелогично, бухгалтера не волнует. И в этом случае перед проектной группой, собирающейся изменить бизнес-процесс, стоит непростая задача: пояснить руководству, что для бизнеса гораздо лучше, когда бухгалтерия не тормозит проведение операций, а занимается тем, что обычно делают бухгалтеры на Западе, а именно, сверкой того, корректно ли занесены данные и правильно ли они распределяются по разным счетам. Впрочем, и в бухгалтериях находятся сторонники изменения бизнес-процессов. В производящей упаковку компании «Промис», по словам ее гендиректора Евгения Слинякова, бухгалтерия была «обеими руками за изменения» — именно это подразделение впоследствии больше всего разгрузилось после внедрения ERP-системы на базе 1С:УПП. Теперь первичную информацию заносят не бухгалтеры, а подразделения, непосредственно работающие с контрагентами: отдел снабжения — по материалам, отдел ИТ — по своей епархии, а бухгалтерия только проверяет, все ли внесено, и рассчитывает накладные расходы.
Впрочем, полностью перестраивать работу компании под логику ERP-системы тоже неправильно. Во многих компаниях существуют уникальные бизнес-процессы, которые по мысли топ-менеджеров приносят организации конкурентные преимущества. Если это в действительности так, то имеет смысл перестроить работу ERP-системы или — что также часто бывает — автоматизировать часть функций не в ERP-системе, а в других программах. Другое дело если пресловутая уникальность не имеет с реалиями ничего общего, а существует только в сознании кого-то из руководителей — тогда изменять работу системы под «уникальный» бизнес-процесс экономически невыгодно. Иными словами, не нужно пытаться придумывать уникальный процесс уборки помещения, если, конечно, вы не владелец клининговой компании, чья фирма знает, как снизить время на уборку помещений на 30%, и пользуется этим преимуществом. «Такие процессы, как выставление счетов или оформление командировок в консалтинговых компаниях, — это не те вещи, которые обеспечивают конкурентное преимущество, поэтому они могут быть выстроены по стандартной логике ERP-систем, — отмечает Наталия Овчаренко, директор по консалтингу “АНД Проджект”. — Российские компании не любят использовать чей-то опыт. А западные будут счастливы. Даже в отчетность по МСФО многие российские предприятия хотят привнести что-то свое, при том что на Западе с удовольствием копируют реализацию учета по МСФО в одной компании и переносят в другую».
Уникальные процессы, ради которых придется изменять стандартные возможности системы, как правило, имеют отношение к основному бизнесу компании, а не к вспомогательным функциям вроде бухучета. Пример уникального бизнес-процесса, реализованного за рамками ERP, — система стаффинга (краткосрочного и среднесрочного планирования людских ресурсов) в департаменте корпоративных систем управления IBS. Несмотря на то что основной системой автоматизации бизнес-процессов в IBS была выбрана платформа SAP, руководство еще в 2005 году решило силами дочерней компании Luxoft разработать специализированное ИТ-решение на базе Microsoft Project (платформа для управления проектами). «Наш бизнес эффективен тогда, когда число и квалификация консультантов соответствует нашим потребностям на каждый день, — говорит директор департамента IBS Григорий Кочаров. — Если не хватает консультантов с определенной специализацией и квалификацией — компания теряет деньги. Если некоторых специалистов в избытке — компания тоже фактически теряет деньги, ведь зарплату и накладные мы все равно выплачиваем, несмотря на простой. Мы научились продавать ровно 100 консультантов при сотне имеющихся. В нашем департаменте — а это более 400 человек — занятость расписана по часам на квартал вперед». Как удается этого достичь — ноу-хау компании. Планирование среднесрочной потребности в людских ресурсах в IBS учитывает очень большое количество различных параметров: это, например, квалификация, опыт предыдущей работы, специализация, знание иностранных языков, возможность ездить в командировки, базовый офис сотрудника, транспортная доступность, разница часовых поясов, отпуска и больничные.
Как утверждают в IBS, рассматривались разные варианты решения задачи, в том числе реализация системы в среде SAP. При сравнении экономической эффективности разных ИТ-решений учитывались полные затраты на разработку, сопровождение, интеграцию с ERP-системой, а также стоимость нескольких сотен лицензий. И в конечном итоге компания сочла более целесообразным разработать специализированную систему.
Опрошенные «Экспертом» компании называют самые разные области, в которых им пришлось отклониться от стандартов выбранной ERP-системы. Одна компания была вынуждена дорабатывать западную систему, поскольку та не поддерживала ведение кредитных лимитов в национальной валюте. Другой собеседник рассказал о непреодолимых противоречиях между собственным подходом к начислению бонусов поставщикам товара и процессом, заложенным в системе, — в результате этот блок пришлось описать и привлечь специалистов по программированию для изменения данной части функционала ERP. Еще в одной компании посетовали на то, что проектная команда «здорово перелопатила блок расчета себестоимости» в отечественной ERP-системе, так как предлагаемые производителем процессы были очень далеки от реальности и не давали руководству наглядной картины, необходимой для понимания себестоимости и формирования цены.
Как видно из примеров, расхождения могут быть в самых разных деталях. И именно их следует тщательно изучить на этапе анализа бизнес-процессов, предшествующего следующей стадии — проектирования, или дизайна. Важно помнить одно: принимая решение о доработках, нужно иметь чувство меры. Когда компания хочет сохранить все-все-все бизнес-процессы и «прогнуть» под них информационную систему, это может быть чревато большими расходами и затягиванием проекта. Кроме того, рано или поздно придется менять нынешнюю версию ERP-системы на более свежую. И если во внедренной системе много доработок, перейти на новую версию будет сложнее.
Как правило, на этапе анализа составляется техническое задание (ТЗ) на разработку информационной системы. В отличие от предыдущих версий ТЗ, которые формируют раньше, еще до выбора системы и подрядчика, в нынешнем ТЗ рекомендуется прописать все задачи максимально детально. Естественно, должны быть четко определены сроки выполнения всех видов работ. При этом, планируя сроки, стоит иметь в виду, что финансовый модуль ERP-системы необходимо запускать не позднее начала второго квартала, а лучше — с 1 января. Это связано с особенностями регламентированного учета: при завершении календарного года бухгалтерия подводит его итоги и с началом следующего года фактически избавляется от необходимости обслуживать огромный массив информации, относящийся к фискальному учету в прошедшем году. «Но такие блоки, как учет основных средств, расчет заработной платы, расчеты с клиентами и поставщиками, можно запускать в ERP-системе с любого периода», — говорит руководитель практики консалтинга по бизнес-приложениям Microsoft Russia Юрий Покусаев.
От проектирования — к реализации
В фазе дизайна, или проектирования, становится понятной модель работы ERP-системы, ее функциональный охват (за что отвечает система и для чего будут применяться другие ИТ-средства). Помимо этого консультанты проектируют пользовательский интерфейс — то, что сотрудники разных должностей и специальностей будут видеть на экране. На этом же этапе ключевым пользователям показывают внешний вид отчетов, который они смогут извлекать из системы. Время на проектирование можно сократить до нуля, если компания решает идти по пути быстрого внедрения — то есть внедряет ERP-систему в ее базовом виде, без доработок.
На этапе настройки и разработки в систему вносят планы счетов, настраивают механизмы получения отчетов. На этой стадии к внедрению подключаются программисты — им предстоит реализовать в программной среде все то, что на бумаге (или в специальных программах) смоделировала проектная группа. Часть функционала настраивается достаточно просто; для серьезных изменений и доработок чаще всего применяется программирование, которое осуществляют специалисты, имеющие право использовать средства разработки и менять исходные коды программ. Стадия настройки и разработки может быть существенно сокращена, если компания решается на быстрое внедрение и программирование (дописывание функционала не требуется).
Затем наступает фаза развертывания системы в компании клиента: прогоняют все операции в присутствии ключевых пользователей — финдиректора, директоров по продажам, закупкам и др. Например, имитируют процесс отгрузки товара и выясняют, как происходит движение информации в системе, какие документы создаются и где эти операции отражаются. Если обнаруживаются серьезные недостатки, программистов просят доработать функционал. Также на протяжении этой фазы обычно происходит интеграционное тестирование — выясняется, хорошо ли взаимодействуют модули системы друг с другом и с внешними ИТ-приложениями.
Одна из проблем внедрений, чреватая неприятностями для клиента, — это ввод начальных данных. Чтобы работать в системе, в нее необходимо поместить массу информации: загрузить справочники клиентов со всеми нужными атрибутами, а также данные о выполняемых заказах, дебиторской и кредиторской задолженности, остатках на счетах, основных средствах и т. п. Хорошо, если внедряющая ERP-систему компания уже использует системы автоматизации (например, для бухучета, управления складом или управления взаимоотношениями с клиентами) — тогда в принципе существует возможность настроить автоматический импорт данных из старых систем в ERP. Но для этого часто требуются услуги программистов и консультантов по настройке импорта данных. В ряде случаев это оказывается дороже, чем набить все вручную. По словам Юрия Покусаева, как минимум в трети ERP-проектов практикуется привлечение временных сотрудников для ввода начальных данных. Такой подход уместен, когда в компании очень много накопленных первичных документов, когда данные отражаются не со всеми необходимыми атрибутами (например, ранее не вносилась информация о том, к какой группе юрлиц относится тот или иной поставщик, а для того чтобы руководство смогло видеть реальную картину взаимоотношений с группой компаний, входящих в один холдинг, этот атрибут нужно добавить к документу). Впрочем, значительную часть работ будут осуществлять высококвалифицированные кадры — им предстоит заниматься выверкой всего того, что внесут временные сотрудники. В конце концов, в ERP-системе работать будут именно они, и, если на означенном этапе неправильно внесут информацию, разбираться со всем придется менеджерам компании.
Для того чтобы правильно загрузить исходные данные, требуется их актуализировать (убрать ненужное — например, устаревшие стандарты, список контрагентов, с которыми компания не работает с незапамятных времен). Кроме того, данные нужно очистить: известны случаи, когда один и тот же клиент или предмет указывались в разных источниках (например, файлах Excel) под разными именами — написание в кавычках и без, а также с ошибками. Особенно часто возникает неразбериха с данными при автоматизации группы компаний — тут без унификации информации точно не обойтись.
«Наибольший риск при загрузке остатков — это позднее начало выполнения таких работ и отсутствие планирования, — говорит Дмитрий Сельков, замдиректора по консалтингу IDS Scheer. — Часто заказчики думают: “Это простая вещь, которую мы возьмем на себя”. Партнер-консультант, разумеется, дистанцируется от этих работ, раз они не входят в контракт. И очень часто ERP-проекты неуспешны по той причине, что в ходе заключительной подготовки к запуску системы в компании клиента начинают одновременно учить пользователей и разбираться со своими основными средствами. А для предприятия размера больше среднего, как показывает моя практика, выполнить эту работу можно не менее чем за девять месяцев, если на это не брошены огромные ресурсы». По словам представителя IDS Scheer, начинать нужно значительно раньше — стартовать с подготовительными работами для загрузки остатков тогда, когда система еще только проектируется. Впрочем, на практике это происходит редко.
Группа «Щекиноазот», на предприятиях которой была успешно развернута система на базе Microsoft Dynamics AX, в ходе внедрения столкнулась с неприятным сюрпризом: когда система уже вот-вот должна была запускаться, вдруг обнаружилось, что достоверных номенклатурных данных об остатках фактически нет. «Многие сотрудники отказывались под роспись вносить данные об остатках, — говорит директор по экономике и ИТ ООО “ОХК «Щекиноазот»” Александр Шарафутдинов. — При том что документы, относящиеся к складским остаткам и взаимодействию с контрагентами, существовали, ряд сотрудников опасались брать на себя ответственность за то, что все эти данные корректны. Мы были вынуждены все очень тщательно выверять совместно с ответственными менеджерами и специалистами. Когда две трети пути было пройдено, наступил перелом — выверка данных заметно ускорилась».
И опыт, сын ошибок трудных
Перед тем как запустить систему в эксплуатацию, как правило, ее «обкатывают» в опытном режиме. Этот этап также часто называют parallel run (т. е. одновременное функционирование новой ERP-системы и старых ИТ-приложений, которые вскоре будут отключены) или же опытно-промышленной эксплуатацией. «Рarallel run позволяет исправить самые крупные ошибки, допущенные в ходе реализации проекта, выявить недоработки. Если отказаться от этапа параллельного функционирования и сразу запустить систему в промышленную эксплуатацию, ошибки всплывут все равно. В первом случае исправить их проще и менее рискованно для бизнеса», — отмечает Дмитрий Сельков. Действительно, если представить себе, что случится с алюминиевой компанией, вовремя не получившей сырье для электролизеров, станет понятно, почему Братский алюминиевый завод около двух месяцев отвел на опытно-промышленную эксплуатацию SAP. По словам Владимира Егорова, руководителя отдела продвижения бизнес-приложений Microsoft Dynamics в России, длительность опытной эксплуатации обычно составляет один-два месяца. Ради большого дела — комплексного охвата важнейших бизнес-процессов в едином информационном пространстве — сотрудникам придется потерпеть: ведь они в ходе этого этапа, по сути, выполняют двойную работу, внося информацию и в старую, и в новую систему. Но игра стоит свеч. С одной стороны, опытно-промышленная эксплуатация в ходе ERP-проекта — отличный шанс проявить себя перед руководством: перспективные сотрудники нередко уходят на повышение. С другой стороны, сама компания повышает эффективность многих ключевых бизнес-процессов — главным образом благодаря прозрачности всех операций и четко налаженным схемам работы, которые создаются и поддерживаются с помощью ERP-системы.
http://www.expert.ru
