Антон Заруев, "Топ-Книга": Ожидания и реальность.

JD Edwards Enterprise One - не самая распространенная ERP на российском рынке. Однако проект внедрения этого продукта в компании "Топ-Книга" дал опыт, потенциально интересный тем, кто только присматривается к пакетам такого класса, особенно розничным компаниям. Им делится Антон Заруев, ИТ-директор компании "Топ-Книга".

Intellegent Enterprise: Что послужило основным толчком к внедрению ERP?

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

Как выбирался продукт?

Выбор продукта начался в 2003 году, проект стартовал в начале 2004 года. Кандидатами были SAP My All in One, Oracle E business Suite и JD Edwards Enterprise One. При выборе принимались во внимание стоимость владения, гибкость и функциональность, и попутно складывалось мнение о консультантах, которые могли бы внедрять такие системы. По всем этим характеристикам наиболее подходящей показалась JD Edwards, которую консультанты рекомендовали как подходящую для розницы, с функциональностью, которую можно наращивать, с приемлемым ТСО, поскольку с ростом числа лицензий не возникало пугающего роста стоимости. Представители компания Deloitte& Touche, которая выступала подрядчиком, не просто приехали и что-то рассказали, а провели у нас несколько дней, познакомились с бизнес процессами и сделали презентацию, максимально привязанную к нашим потребностям, что качественно отличило их от других консультантов.

Чего вы ждали от внедрения?

Плановые параметры проекта были следующие: образуется проектная команда из специалистов Deloitte (не более 6 человек) и "Топ-Книги" (5 функциональных специалистов - логистиков и финансистов, 2 системных администратора и 6 разработчиков). Планировался одномоментный запуск базовой функциональности модулей логистики и финансов в центральном офисе, в одном магазине и одном Cash&Carry. Ожидаемая продолжительность этой первой фазы проекта - 8 месяцев.

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

И насколько ожидания оправдались?

На данный момент с помощью JD Edwards мы автоматизировали 5 складов, один магазин и один C&C, систему мы эксплуатируем уже год. Общее число рабочих мест - около 500. Параллельной эксплуатации старой и новой системы не было. К моменту запуска прозрачность движения товаров и финансов была обеспечена, и здесь ожидания оправдались, а вот по всем остальным направлениям жизнь внесла коррективы, и существенные. В процессе работы над проектом были закуплены еще два модуля, которые первоначально не планировалось покупать, поскольку первоначально консультанты утверждали, что того, что уже есть, будет достаточно. Сроки первой фазы проекта выросли почти вдвое. Число сотрудников ИТ-подразделения увеличилось. Общее число ИТ-систем в компании снизилось, но незначительно. Замена существующих ИТ систем произошла только для всех разновидностей складского ПО. 1С продолжает использоваться там, где еще нет JD Edwards, а все данные консолидируются в ERP. Остальные "старые" системы эксплуатируются по-прежнему. Исчезли завышенные ожидания, что ERP нам все заменит. Со временем используемое сейчас "старое" ПО мы или заменим либо на соответствующие модули ERP, либо на другие специализированные программы более удовлетворяющие современным требованиям.

Число модификаций системы на данный момент превысило 270. Обычно подобные проекты ограничивались 4 - 10, ну максимум 30 изменениями базового функционала. Также, за несколько месяцев до планируемой даты запуска стало ясно, что одномоментно во всех подразделениях запуститься не удастся, возможен только поэтапный запуск. Кроме того, решение для магазина, разработанные на первом этапе, оказалось слишком сложным и тиражировать его пока нельзя. Решение для C&C было еще более неудобным в эксплуатации. С начала мая этого года проходит опытную эксплуатацию вторая версия ПО для Cach&Carry, более пригодная к тиражированию. Будем разрабатывать более простые в эксплуатации, более надежные с точки зрения падения каналов связи и удобные для персонала магазина решения. В то же время решение для складов оказалось удачным и оно тиражируется. Но для обеспечения непрерывности бизнеса мы были вынуждены разработать решения на случай форс-мажоров приводящих к недоступности системы, главные из которых - сбои каналов связи и остановка системы в центральном офисе по каким либо причинам. Сейчас работа на складах не остановится. Есть регламент перехода на резервную систему, это обновленная версия той, что раньше использовалась на складах. После устранения сбоя происходит "закачивание" информации в ERP и работа продолжается как будто остановки не было. За год у нас произошло два существенных сбоя. Последний показал, что эта схема позволяет складам отгружать товар оптовым покупателям и в свои магазины без существенных потерь, что принципиально важно для торгового предприятия.

Почему же расхождений оказалось так много?

Причин такого большого числа модификаций несколько.

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

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

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

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

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

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

Вы не боялись, что этим внедрением сломаете хорошо налаженный и прибыльный бизнес?

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

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

Как восприняли новую систему сотрудники компании?

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

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

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

Большую роль сыграла самоотверженность команды. Все были очень четко настроены на то, что система будет настроена и запущена Сотрудники с отношением "работаю с 9 до 18, свое сделал и ушел" в этой команде не приживались. Царил дух взаимопощи, люди не жалели ни времени, ни усилий, и главное - это было интересно. Работали с пониманием, что все, что делается в проекте, есть будущее компании, и наше в ней будущее. Задерживались допоздна, работали по выходным, - и это не считалось героизмом! Я под самоотверженностью понимаю способность концентрироваться и добиваться результатов в нужный момент, невзирая на "сопли, вопли" и прочие помехи.

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

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

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

Положительно сказалась готовность всех сторон пересматривать планы проекта. Практически такой проект - это изменение инфраструктуры компании, в нем много неопределенностей, но все придерживались мысли, что лучше делать дольше, но правильно, чем абы как запустить поскорее. Конечно, не по всем аспектам этот подход был выдержан на 100%, но ведь бесконечно совершенствовать систему без запуска означает тратить деньги без отдачи. Поэтому, когда понадобились дополнительные деньги, их дали, а не заморозили проект.

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

С какими еще проблемами вы столкнулись и какие новые планы собираетесь реализовать?

Одна из проблем - вовлеченность топ-менедежеров, руководителей подразделений в использование ERP. Ведь для них специализированных мест в системе пока нет, система транзакционная, а им для управления нужна общая картина, аналитика. Это стало некоторым сюрпризом и разочарованием и именно в этом направлении мы будем продвигаться. По прозрачности финансов и товародвижения уже видны явные выгоды, когда мы уже можем любому товару посмотреть положение дел. Но появилась острая нужда в системе корпоративной аналитической отчетности, поскольку сама ERP таких возможностей в достаточном объеме не имеет. Так что аналитику мы пока получаем выгружая данные из ERP в "настольные" системы: Excel, Access через ODBC. Это конечно сервер нагружает, но куда деваться?

В начале 2005 года стало ясно, что дальнейшее развитие компании требует внедрения системы бюджетирования. Рассмотрели модуль бюджетирования, который есть в JD Edwards, но он оказался очень слабеньким. Сейчас уже второй месяц идет проект по внедрению Oracle EPB. Поток модификаций ERP сейчас уменьшился, но не исчез: и новые разрабатываются, и старые переделываются, в том числе решения для магазинов.

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

Из за большого числа модификаций апгрейд системы для нас очень затруднен. Переход на следующую версию практически означает переписывание всех модификаций заново, так уж JD Edwards устроен. Апгрейд фактически равнозначен еще одному внедрению. Он, разумеется, пройдет гораздо проще, поскольку и проще данные перекачать, и руку на модификациях мы уже набили. Модификация в данном случае - это заново написанный объект, с которым утилита стандартного апгрейда не будет знать, что делать. Но пока в новой версии 8.11 мы не увидели ничего такого, ради чего стоило бы запускать такую сложную процедуру. Если мы увидим некий качественно новый уровень, который позволит компании сделать существенный скачок, отказаться от модификаций, которые у нас есть, тогда будет иметь смысл рассматривать вопрос апгрейда. Хуже, когда мы сталкиваемся с ошибками самой системы, тут уж приходится искать обходные пути.

Кроме того, в ближайших планах создание системы горячего резервного копирования, аналитического расширения JD и дальнейшее развитие нашей корпоративной сети передачи данных.