ERP-опыт

Где и чему вы учились?

​ В 1996 г. закончил Липецкий государственный технический университет, факультет автомитизации и информатики. Пришел на Новолипецкий металлургический комбинат, где занимался промышленной автоматизацией, в том числе автоматизацией прокатных станов. Затем занимался бизнес аналитикой, автоматизацией основных процессов блока экономики и финансов.

Параллельно получил второе высшее образование в Санкт-Петербургском инженерно- экономическом университете на факультете автоматизации управления предприятием. Это можно сказать, был один из первых в России «факультет ERP», на рубеже двухтысячных годов там изучались актуальные в то время программные продукты. Из теоретических были такие дисциплины как теория экономических информационных систем, теория СУБД, теория автоматизации экономических процессов. Второе образование помогло систематизировать практические навыки и знания в части автоматизации бизнес-процессов.

Как складывалась карьера дальше?

Я переехал в Москву и пару лет работал в компании «Протек», крупнейшем дистрибьюторе медицинских препаратов и прочей продукции для аптек. Там была очень неплохая организация управления в ДИТ, особенно в части процессов управления инфраструктурой и ИБ. Я работал системным аналитиком в отделе, который занимался проектированием и разработкой аналитических систем информационной поддержки поставочно-сбытовой деятельности. В частности, принимал участие в разработке систем поддержки принятия решений для подразделений Коммерческого департамента в части закупок и ценообразования.

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

В 2008 г. я пришел в Hoff, это был совершенно новый бизнес, открывавшийся по франшизе австрийской компании kika. Основной задачей в начальный период работы компании был быстрый выход на рынок, начало продаж мебели и товаров для дома. Сейчас интересно вспоминать то время, когда мы открывали первый гипермаркет на Новой Риге. Продажи начались в апреле 2009 года, а активная подготовка к открытию началась летом 2008-го, когда была сформирована основа команды. Было очень много специфики, которую необходимо было быстро осваивать и адаптировать к нашему рынку – ведь по сути наш формат не имел аналогов в России. По итогам открытия первого гипермаркета мы сделали правильные выводы, учли ошибки; если говорить языком проектного управления, то успех проекта первого гипермаркета стал основой для создания, я бы сказал, нашей внутренней «лучшей практики», шаблонов планов, подробных чек-листов, которые сейчас используются для организации слаженной работы большой команды разных подразделений, открывающей новые гипермаркеты. Наличие такой «лучшей практики» очень помогает предусматривать и справляться с нестандартными ситуации, которые являются вполне обычным делом для проектов такого рода - это и проблемы со стройкой, и с каналами связи, и с поставками специфичного оборудования. Зато теперь мы к открытию магазина относимся довольно спокойно. Например, моя роль в цикле открытия в основном сводится только к контролю соблюдения сроков нескольких ключевых этапов открытия и бюджетных цифр в части тех задач открытия магазина, за которые отвечает Дирекция по ИТ (поставки ИТ-оборудования, работы по монтажу инфраструктуры, настройка информационных систем, обучение сотрудников).

Каков ИТ-ландшафт Hoff?

При запуске первого магазина одной из ключевых составляющих успешного старта было быстрое внедрение ERP-системы MS Dynamics AX 4.0. В общем, у нас был перед глазами прототип бизнеса – австрийская kika, и мы понимали, что при наличии работающего прототипа для быстрого старта лучше взять его за основу и не изобретать велосипед. Был ряд отличий, некоторые из них были существенными, что определило некоторые из направлений, в которых мы развивали ERP в дальнейшем. Например, у австрийцев не было понятия «распределительный центр» (РЦ), с которого происходит дистрибуция значительной части товара по гипермаркетам, а у нас РЦ появился с самого начала, что нашло свое отражение в необходимости адаптации архитектуры системы. Были и серьезные отличия, связанные с российским бухучетом и правилами таможенного оформления импорта. Что касается ИТ-инфраструктуры, то и здесь мы воспользовались опытом австрийских коллег в той степени, в которой это было применимо. Например, использование тонких клиентов на большинстве рабочих мест в гипермаркетах было отличной идеей, которую мы позаимствовали и упростили себе жизнь в плане администрирования рабочих мест. Кроме того, мы с самого начала работы используем аутсорсинговый ЦОД, что позволяет существенно снизить затраты ресурсов и времени на поддержку этого компонента ИТ-инфраструктуры, и больше внимания уделять развитию функциональности бизнес-приложений.

Если говорить о функциональности, которая используется в нашей ERP-системе - то это, по сути, все процессы основной деятельности компании, связанные с товародвижением: закупки товара, импортные и локальные поставки, внутренняя дистрибуция, продажа товаров и услуг с документальным оформлением в розничных магазинах, оформление заказов на продажу, формируемых Интернет-магазином, учет оплат товара и услуг, произведенных на кассе или на веб-сайте, послепродажное обслуживание и обработка претензий. Что касается финансового учета, то в ERP формируются только финансовые проводки, связанные с получением, продажей и отгрузкой товаров, они формируются сразу по РСБУ, после чего они импортируются в 1С в сгруппированном виде без номенклатур товара. В 1С ведется собственно финансовый учет и ведется расчет налогов – в общем, достаточно стандартный подход.

Как вы относитесь к тезису о том, что внедрение ERP лишает бизнес гибкости, сковывает его?

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

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

Что касается нашего случая, то при принятии в 2008 г. решения взять за основу кастомизацию Dynamics AX 4.0, выполненную нашими австрийскими партнерами, мы исходили из основной цели на тот момент – скорейшего выхода на рынок. Поэтому важным фактором для нас было наличие в выбранной системе в той или иной степени готовых моделей процессов, уже базовым образом технологически связанных между собой внутри платформы AX. В дальнейшем это обеспечило для нас возможность упростить доработку и развитие системы, а тщательное документирование изменений дает возможность не быть слишком сильно «привязанными» к конкретной команде разработчиков, будь то сотрудники компании, привлеченные партнеры или фрилансеры.

Давайте более подробно поговорим о том, какие именно бизнес-процессы реализованы в ERP Hoff, ключевых параметрах вашей учетной системы и немного о технической инфраструктуре.

Укрупненная функциональная карта нашей действующей ERP-системы выглядит примерно так:

- Управление мастер-данными – это основные справочники, такие как информация о товаре, поставщиках, договорах, клиентах и т.д.

- Закупочная деятельность, то есть создание, изменение, подтверждение заказов на покупку товара

- Ценообразование

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

- Приемка товара – блок функций, связанных с оприходованием накладных, учета недостач и брака.

- Внутренняя логистика – планирование и отражение операции внутренней дистрибуции, перемещения товара внутри компании.

- Продажа товара. Этот процесс, пожалуй, в наибольшей степени отражает специфику розничных процессов компании Hoff. У нас два вида продаж: традиционные продажи товара с полки (Cash & Carry), и продажи с документальным оформлением заказа на собственно товар, а также на дополнительные услуги, например, доставка и сборка мебели. Товары Cash & Carry – это товары для дома, всегда доступные в торговом зале на полках, стеллажах и в корзинах. Это товары, которые покупатель самостоятельно кладет в тележку и оплачивает на кассе, как в обычном супермаркете. На кассе все покупатель оплачивает товар и получает чек. Информация об оплате товара с реквизитами чека попадает в ERP с задержкой 1-2 мин. Если в дальнейшем покупатель обращается с просьбой о возврате товара, то такой чек будет найден специалистами службы сервиса в ERP по его номеру. Товары, требующие документального оформления продажи, находятся в торговом зале как выставочные образцы. Типичным примером является любая мебель. Продажа такого товара производится с оформлением документа «Заказ на продажу» в ERP-системе.

Например, покупатель выбрал понравившийся ему диван из выставочных образцов. Свободного дивана на стоке магазина нет. Продавец оформляет заказ на продажу, в котором резервирует товар с распределительного центра. Или если дивана нет на РЦ, то есть возможность зарезервировать его под нашего клиента из заказа на покупку, который пока в пути от поставщика. Мы, конечно, стараемся обеспечить наличие наиболее продаваемых позиций непосредственно на складе гипермаркета, но если нужный товар там отсутствует, то его можно зарезервировать из любого возможного источника. Итак, товар под клиента можно зарезервировать: на стоке гипермаркета; на внешнем складе региона; на РЦ в Москве; из заказа на покупку, который пока в пути от поставщика. Резерв работает по принципу «кто первый, за тем и преимущество», другими словами, товар не должен быть повторно зарезервирован кем-то еще. В централизованной системе с единой базой данных это требование реализуется наиболее просто. Свободен ли товар, окончательно проверяется при разноске заказа на продажу. После оформления Заказ на продажу передается в кассовую систему магазина, на кассе проводится оплата, информация об оплате попадает в ERP с задержкой в 1-2 мин. После фиксации оплаты в ERP становятся возможными проведение операций послепродажного обслуживания (это формирование документов выдачи товара или документов для доставки товара клиенту), а также операции, связанные с рекламационной работой – регистрация претензий, возвратов и обменов товара и т.д.

- Рекламационная работа (претензии, обмены и возвраты товара)

В настоящее время в системе работает до 650 конкурентных пользователей. Каждый гипермаркет дает до 50 одновременных коннектов, еще есть Центральный офис и Распределительный центр. Общее количество пользователей – более 1500.

Что касается технической инфраструктуры, то я попробую проиллюстрировать ее на примере с покупкой дивана, который я уже приводил. Технологически это выглядит следующим образом: продавец-консультант на своем аппаратном тонком клиенте заходит на свой удаленный рабочий стол с помощью Citrix. Citrix, сервера Dynamics AX и базы данных системы расположены во внешнем Датацентре. Корммуникация Датацентра с бизнес-юнитами обеспечивается посредством защищенного соединения VPN. На удаленном рабочем столе запущен клиент Dynamics AX. Продавец создает заказ на продажу, где в окне выбора резерва указывает, откуда зарезервировать диван и в каком количестве. Заказ «разносится» в Dynamics AX и выводится на печать на сетевой принтер на рабочем месте продавца. Если есть необходимость в дополнительных услугах, таких как доставка, то это отражается в заказе. Далее покупатель проходит на кассу, где оплачивает товар. Если, например, покупатель заказал доставку, и товар находится на внешнем складе, то специалисты склада в дальнейшем проконтролируют формирование реестра таких заказов в ERP, загрузку маршрутов доставки от внешнего транспортного провайдера и непосредственно перед доставкой распечатают доставочные документы.

В каком случае применима централизованная инсталляция ERP-системы, какие от этого плюсы, и какие риски при этом возникают?

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

В нашем случае имеет место и технологическая, и функциональная централизация. Одна инсталляция системы включает все необходимые функциональные модули. Все основные операционные процессы нашей сети реализованы в единой системе. Специфика формата бизнеса такова, что розничному и логистическому персоналу необходимо видеть сток в режиме «онлайн». Наиболее просто такое требование обеспечивается реализацией всех процессов товародвижения в единой базе данных. Нет необходимости решать проблемы, связанные с интеграцией разных функциональных модулей и физически отдельных баз данных.

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

Если говорить о рисках централизованного решения, то они, как часто бывает в жизни, - оборотная сторона преимуществ. Главным по степени влияния на бизнес является риск отказа технологических компонентов центральной системы – серверов приложений или сервера базы данных. Причиной недоступности некоторых сервисов может быть также проблема с каналами связи. Ошибки при изменениях программного кода могут обойтись дороже, как и случайное повреждение данных, вызванное некорректными действиями персонала. Отдаленным во времени, но тем не менее достойным внимания может быть риск замедления производительности системы в результате существенного роста количества бизнес-юнитов при дальнейшем развитии компании.

Рисков в теории нельзя избежать полностью, но их можно минимизировать, сведя вероятность их возникновения к близкой к нулю. Для того, чтобы эффективно управлять рисками, необходимо выявить степень их влияния на бизнес в разрезе ключевых бизнес-процессов, и далее провести мероприятия, направленные на максимальное устранение такого влияния. Если говорить о перечисленных основных рисках централизации основной учетной системы, то недоступность основной системы может привести к потерям выручки, что, разумеется, неприемлемо. Этот риск минимизируется разумной избыточностью критических серверов, использованием кластеризации и технологий горячего резервирования СУБД. Кроме того, кассовая система гипермаркета может работать в режиме «оффлайн» по отношению к ERP, в ее базе хранится информация о ценах, а также еще не оплаченные заказы на продажу. Риски, связанные с каналами связи, уменьшаются путем резервирования каналов и наиболее критичного сетевого оборудования – в нашем случае инвестиции в резерв себя полностью оправдывают, поскольку размер нашей торговой точки, гипермаркета, достаточно велик. Далее, нельзя сказать, что любые ошибки в модификациях кода системы приведут к серьезным потерям, но понятно, что лучше использовать одну и ту же четко регламентированную методологию разработки, тестирования, приемки доработок и их переноса на рабочую систему вне зависимости от сложности программной модификации. Риск случайного повреждения данных присутствует в любой системе, с которой работают администраторы, обладающие правами полного доступа. Для того, чтобы избежать потерь, все опасные с точки зрения потери данных действия в системе, строго регламентированы и журналируются на системном уровне.

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