В. Прудковских. Практика подготовки к внедрению ERP-систем.
Источник: «Корпоративные системы» — 2007, №4.
Подписание контракта на внедрение
Внедрение ERP-системы — это три большие покупки: собственно программа со стандартной функциональностью; дополнительная настройка, осуществляемая вендором; «железо» — покупка необходимого аппаратного обеспечения.
На стадии заключения контракта по внедрению ERP обычно невозможно достоверно определить наиболее важный показатель — объем проекта (и, соответственно, его временные рамки, стоимость и т. д.). Поэтому вендоры очень внимательно следят за тем, что входит в проект, а что нет. Компании со своей стороны стоит в рамках контракта также настоять на ряде важных моментов.
Объем проекта и вопрос дополнительных работ
Согласно будущему контракту вендор обязуется внедрить данную программу за определенное время. В процессе тендерного отбора вендора у всех участников есть стремление уменьшить и время, и деньги. Понимая, что подобная минимизация обязательно приведет к проблемам в будущем, вендоры обычно включают в контракт четкие положения о том, что входит в объем проекта по контракту, и оговаривают, что все дополнительные работы требуют дополнительной оплаты. Как показывает личный опыт, это очень значительный объем работ. Поэтому стоит предусмотреть создание сразу двух резервных фондов (времени и денег): на расширение объемов проекта на стороне вендора и на стороне клиента.
Что означает на практике не предусмотреть такой пункт? Одна из FMCG-сетей, действующая и в Украине, при заключении контракта оговорила лишь процесс внедрения, обойдя дополнительные работы вниманием (предполагалось, что в Украине будет проведена адаптация системы, параллельно внедряемой во всей компании). В результате каждый запрос на изменения проходил как почасовая работа ИТ-специалистов вендора, и, кстати, вовсе не от жадности последнего. Внедряющая организация планирует время своих сотрудников и, когда появляются непредусмотренные заказы клиентов на мелкие работы, просто вынуждена считать их по максимальной ставке. Как следствие компания понесла не только повышенные затраты, но и, что более важно, незапланированные проблемы решались достаточно долго.
Радикально другим путем пошла одна из сетей в секторе игорного бизнеса. Работы по внедрению системы велись «в открытую» — специалисты заказчика потоком высказывали пожелания, которые (после необходимой обработки) немедленно включались в объем проекта. Здесь изначально в проект были включены только покупки необходимых лицензий на программное обеспечение и инсталляцию стандартной функциональности системы.
Скажем так: лучшее решение для большинства компаний — среднее между упомянутыми примерами. Это означает купить лицензии на программу, на функционалы, оговорить объем проекта, создать резервный фонд. К вопросу о дополнительных работах — эту процедуру стоит максимально упростить. Для обоих случаев — для случая, когда компания заказывает дополнительные работы, и случая, когда компания заказывает (безоплатно) исправление проблем с купленной стандартной функциональностью системы. Реально для таких заявок единственно важное — их фиксация, и чем меньше бюрократии, тем лучше. Если контрактом будет предусмотрена специальная форма на английском языке на пяти страницах с требованием дополнить заявку скриншотами проблемы или детальным описанием заявки на изменение стандарта, то множество мелких проблем не будет решаться или будет решаться крайне медленно. Лучше взвалить бюрократию на вендора — от заказчика обязана поступить почта с кратким описанием проблемы, вендор делает всю бюрократию на своей стороне и реагирует в определенное контрактом время.
Команда по внедрению
Чаще всего ответственным за проект становится финансовый директор компании, что совершенно верно. Но непосредственное руководство должно быть возложено на человека, единственной работой которого будет проект. В противном случае проект останется без оперативного руководства, ведь финансовый директор или главный бухгалтер имеют большой объем основной работы.
В качестве операционного управляющего проектом целесообразнее назначать представителя компании, а не привлекать на временной основе специалиста из компании-вендора, что иногда имеет место. В последнем случае руководитель проекта будет поставлен на пересечении интересов вендора и клиента — это может только повредить. Такой специалист будет отлично знать программу, но не потребности компании, и лучше понимать аргументы внедряющей организации. Это кажется малой проблемой — потребности можно пояснить, интересы — соблюсти. Но различия могут быть слишком значительными. К примеру, проект упомянутой выше FMCG-сети частично приостановился на 1,5 месяца только потому, что руководитель проекта (сообразуясь с информацией от вендора и будучи сам ИТ-специалистом) счел работы по фронт-офису завершенными, в то время как бухгалтерия компании считала иначе.
Это, повторюсь, может показаться забавным, но в понимании руководителя проекта и внедряющей организации термин «работает» означал работоспособность кода и, как максимум, необходимость настройки: «включить функцию расчета», «добавить расчет НДС», «настроить расчет себестоимости по подразделениям» и т. д. В понимании бухгалтерии «работает» — значит, можно учитывать транзакции, и результат будет соответствовать проектным требованиям. Как сказано выше, завершение работ по фронт-офису отложилось на 1,5 месяца.
Ограниченно позитивным решением будет найм специалиста по данному программному продукту со стороны либо прохождение обучения и назначение на данную должность одного из руководителей ИТ-подразделения компании. В первом случае мы получаем человека, мало знакомого с нуждами компании; во втором — человека, не имеющего представления о финансах, транзакциях и т. д. Поэтому наилучшее решение — заместитель финансового директора, прошедший обучение на уровне ключевого пользователя системы. Сходным образом стоит выбирать ключевых пользователей — уровень заместителя руководителя подразделения (такие пользователи уже могут быть лишь частично освобождены от рутинной работы).
Важно, чтобы команда соответствовала этому слову — «команда». Например, чаще всего каждое подразделение готовит собственные требования к функциональности системы самостоятельно. Нет, вся работа должна вестись с участием всей команды и на этапе проектирования, и на этапе внедрения. Тогда не получится, что в результате внедрения ERP, как и раньше, продажи создают какие-то свои транзакции, которые не совместимы с бухгалтерскими, которые, в свою очередь, надо детализировать для целей бюджета. Все всё должны делать вместе — это хороший принцип.
План-график внедрения
Современные средства того же Microsoft Project позволяют сделать такой план наглядным и хорошо структурированным. Большая рекомендация — настоять на том, чтобы он был общедоступен для сотрудников вендора, ключевых пользователей, руководства компании. План можно положить на внутреннем сервере и обязать руководителей проекта со стороны компании и вендора вносить в него малейшие изменения. Только так можно держать руку на пульсе и вовремя ликвидировать возникающие затруднения.
Впрочем, дело не столько в инструментарии, сколько в одном «подводном камне».
План-график — детище вендора, которому больше всего важно, чтобы план выглядел быстрым и красивым. Но ведь проблемы-то будут! Для их решения рекомендую оговорить, что новые работы в данном разделе не стартуют до полного завершения предыдущих.
Все ресурсы ограничены — и людские, и временные. Если начать следующий этап работ, не покончив с проблемами предыдущих, мы получим клубок, распутывать который долго и трудно. Подобное «проталкивание» в условиях искусственного цейтнота подробно описано в теории ограничений.
Смета внедрения
Смета, создаваемая вендором, всегда выглядит очень красиво, как и план-график, упомянутый выше. На этапе утверждения ее стоит чуточку «подпортить» внесением дополнительных работ, о которых говорилось выше. Также следует настоять на прозрачности таких цифр в смете, как «управление проектом», «командировочные расходы», «расходы на связь» и т. д. Каждая цифра сметы должна быть по факту утверждена заказчиком и подтверждена документально (внутренними проектными документами, документами третьих сторон). В общем же виде смета здесь не очень специфична.
Обучение и учебная информация
На этапе внедрения обучение проходят лишь так называемые ключевые пользователи — обычно руководители подразделений или заместители, которые впоследствии должны проводить обучение остальных специалистов. Можно оплатить и дополнительное обучение, но ведь люди увольняются, подразделения расширяются, создаются новые.
Поэтому для быстроты и безошибочности дальнейшего обучения учебные материалы должны быть максимально наглядными и полными. Это по своей воле никогда не захочет делать вендор, ему удобнее (и с большей прибылью) сделать инструкцию в Excel, предусмотрев лишь основные операции. А по мнению автора, нет ничего более наглядного, нежели видеоинструкции с аудиосопровождением, полный комплект которых размещен на внутреннем сервере компании. Например, следующие видеоинструкции: «как ввести накладную на покупки сырья»; «как создать новый необоротный актив»; «как исправить сохраненную ошибку», «неверное подразделение» и прочее. Пара дней работы с тестовой базой — и новый сотрудник способен выполнять десяток разнообразных операций. А также не имеет никаких шансов сказать, что он не обучен. Такие материалы легко сделать с помощью многих простых программ (например Camtasia Studio).
Впрочем, можно пойти и более консервативным путем — скриншоты и текстовые описания. И лучше добиться этого от вендора путем внесения требования о детальном руководстве пользователя в устав проекта, причем таким образом, чтобы на основе таких материалов проходило обучение ключевых пользователей. Это позволит внести в обучающие материалы необходимые изменения.
Стандарт и настройка
Мы привыкли к тому, что «стандарт» — это коробка с программой, которую можно инсталлировать и работать в ней.
В отношении ERP это, к сожалению, не срабатывает. Нам продают «серый экран», хотя вендоры всегда заявляют о наличии стандартного функционала. Его в лучшем случае можно в течение нескольких недель доработать. Поэтому, когда планируется решение о покупке чего-либо стандартного, следует либо настоять на обязательной проверке работоспособности «стандарта», либо оговорить в контракте, что все работы по доработке ведутся силами и за счет вендора (или производителя). В противном случае можно оказаться в ситуации, когда вендор за счет компании будет дорабатывать то, что уже продал в качестве работоспособного функционала.
Принятие бюджета внедрения
На этом вопросе можно не останавливаться подробно — эти бюджеты не являются чем-то специфическим.
Cобственно бюджет. Его стоит разделить на расходы по покупке программы, внедрению и покупке необходимого оборудования. Основываясь на имеющейся у автора практике, все расходы на покупку и внедрение ERP-системы вполне способны уложиться в рамки: (1) счета капитальных инвестиций на покупку / создание нематериального актива, (2) счета инвестиций на покупку / создание основных средств (это нужно для покупки железа) и (3) счета учета малоценки.
Бюджет времени. Это можно рассматривать как дополнительную детализацию к план-графику внедрения, подписанному с вендором.
Бюджет «голов». Важно, чтобы компания была готова к найму дополнительного временного персонала в случае необходимости, поскольку низкая скорость внедрения — слишком дорогое удовольствие.
Внутренняя подготовка компании к внедрению
Собственно, следующее, что делает вендор после подписания контракта, это выявляет юридическую и физическую структуру компании, а также утверждает будущий план счетов по всем видам учета. Подготовиться к этому этапу стоит заранее, так как сам вендор способен лишь собрать сведения о текущем состоянии. В то же время сама компания может поработать над тем, чтобы система была настроена и на ближайшее будущее.
Что касается плана счетов, то для его адекватного создания, по мнению автора, стоит пойти от обратного — от отчетности. Это позволит полноценно описать все, что компания хочет видеть в системе.
Особое внимание нужно уделить оперативной производственной отчетности, отчетности в продажах и в маркетинге. Очень часто именно она весьма хаотична, и внедрение ERP может помочь собрать ее воедино, стандартизировать и сделать общедоступной. Примерами могут быть данные о себестоимости на переделах, данные о трудовых затратах временных работников (как в производстве, так и в маркетинге), информация о заключенных контрактах в продажах (это может иметь существенное значение для отчетности по международным стандартам), информация о клиентских счетах (скидки, наценки, расходы по заказам клиентов) и многое другое. Зарабатывающие подразделения обычно имеют возможность собрать огромный массив аналитических данных, необходимых для улучшения продуктов и услуг. Но чаще всего здесь действительно царит неразбериха. С ней можно бороться средствами будущей ERP, а в дальнейшем создать полноценную CRM.
Что касается описания бизнес-процессов, то здесь есть своя специфика. Работать приходится со всеми процессами, которые будут создавать транзакции в системе, — значит, работы достаточно много. Результатом описания должна быть четкая привязка к плану счетов: «какие процессы к каким последствиям в учете приводят» и «какие люди какую информацию в систему вносят». Это важно и для определения круга будущих пользователей системы.
Небольшое лирическое отступление. ERP стоит тем дороже, чем больше у системы пользователей. Но автор уверен, что внедрение ERP должно сопровождаться расширением круга людей, которые вносят в систему информацию об операциях. Как обычно попадают данные в бухгалтерию? Акт выполненных работ, накладная, налоговая накладная — хорошо, если придет контракт вовремя. Поэтому учетная служба учитывает транзакции только по документам. Но часто значительные массивы данных не имеют документального подтверждения, и лучше всего об этом знают профильные службы.
Пусть юридическая служба вносит в систему сведения о состоянии судебных дел по взысканию задолженности, пусть ИТ-отдел вносит информацию о расходах на связь (т. к. счета доходят после отчетности), пусть в отделе продаж будет создано специальное подразделение, которое будет вносить информацию о контрактах, продажах, возвратах и т. д. (то же самое нужно сделать и по отношению к отделу закупок). Когда все это сделано, тогда учетная служба перестанет заниматься счетоводством и займется своей прямой обязанностью — правильным отражением транзакций и компиляцией отчетности.
ERP позволяет настроить раздельно права ввода данных и их учета в системе, так что это возможно и стоит сделать.
Еще немного того, что стоит делать при внедрении
Стоит уйти в сеть. Это не идея автора статьи — это рекомендации, даваемые такими специалистами по управлению, как Портер, Риддерстрале и Нордстрем. Правоту этой идеи несложно ощутить, присутствуя на очередной встрече по подготовке к совещанию по сбору сведений для встречи по определению повестки дня заседания…
Процесс внедрения системы очень дорог. Поэтому команда по внедрению должна обладать поразительной пропускной способностью, не задерживая даже на день решения ни одной возникающей проблемы. Как это будет сделано — удел конкретного проекта. Но пусть все ключевые лица проекта будут иметь лаптопы и мобильный выход на сеть по GPRS, пусть они меняют план счетов после конференц-связи по Skype. Пусть они также решат проблему с возникшим сбоем при компиляции отчета о прибыли и убытках, а с помощью доступа к программе по серверу терминалов устранят его. Это очень правильно — быть быстрыми.
Стоит обойтись одним внедрением. Существует два варианта внедрения ERP. Первый — когда система устанавливается в каждом подразделении и между ними и центральным офисом осуществляется ежедневная репликация обновленных данных. И второй вариант — когда внедрение делается «единожды». В отдельных подразделениях не устанавливается ничего — ни программное обеспечение, ни оборудование — только доступ к центральному компьютеру по серверу терминалов (например Citrix). Это требует широкой связи по сети, но избавляет от множества проблем. Более сложно, но уже возможно в Украине — перейти на работу с тонкими клиентами.
Стоит оставить Excel и Word. Эти программы еще долго будут актуальны для заполнения отчетности, поскольку настройка и поддержка отчетности внутри ERP в украинских реалиях часто просто нерентабельна.
Еще немного того, чего не стоит делать при внедрении
Не стоит делать пилотные проекты на малых подразделениях. Это часто любят делать иностранные компании, полагая, что небольшой офис будет отличной обкаткой процесса внедрения. Но небольшой (особенно недавно созданный) офис не выполняет подавляющего числа операций, которые имеет головная компания, не имеет отлаженных процессов. Внедрение в нем ERP в качестве пилотного проекта не только не даст необходимого опыта для всей компании, а напротив, внедрение будет сопряжено со значительными дополнительными трудностями.
Не стоит доверять отдельные фронты работ разным вендорам. Наилучшее решение — собственная служба сопровождения. Автору хорошо известна компания, имеющая почти 5000 пользователей, которые поддерживаются всего парой десятков специалистов. Половина из них работает над разработкой, половина — над внедрением и поддержкой. И никаких десятков вендоров в разных странах.
В случае если создание собственной службы на данной стадии нерентабельно, стоит централизованно работать через одного вендора (даже внедряя систему в разных странах). Пусть субподрядчики будут его заботой, но таким образом обеспечится единообразие системы.
Не стоит разделять процесс на части. Старт должен быть полным для всей головной компании. Если с 1 марта стартуют продажи, с 1 июня — производство, а с 1 января — бэк-офис, то это может сработать на усиление хаоса от разнообразия учетных систем.
Стартовать лучше всего с 1 января (точнее, с 3, введя задним числом пару дней). Тем самым будет соблюдена отличная итальянская новогодняя традиция — компания в новом году избавится от множества старой рухляди и заработает на современной системе управления.