В сентябре 2001 совместно с PricewaterhouseCoopers компания ЦВ "Протек" разработала стратегию информационного развития и приняла решение переходить на тиражную ERP. Первый этап внедрения стартовал с декабря 2002 года. Обычно о том, с какими проблемами сталкивается компания при внедрении ERP-системы, говорится вскользь. Виктор Горбунов, начальник отдела бизнес-процессов, функциональный архитектор ERP-системы в ЦВ "Протек", не скрывает ни проблем, с которыми столкнулась его команда при внедрении Oracle E-Business Suite, ни реальных результатов, которые удалось получить за два года ведения проекта.

Intelligent Enterprise: Как бы вы охарактеризовали уровень автоматизации в "Протеке" до внедрения Oracle E-Business Suite?

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

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

Компания «Протек»

Существует с 1990 года и имеет крупнейшую в стране дистрибьюторскую сеть. Имеет центральный склад в Москве и сорок региональных складов по России, 32 региональных торговых представительства, общая площадь складов более ста тысяч квадратных метров. Более 700 поставщиков, более 18 тыс. клиентов, более 8600 наименований товаров в ассортименте. В год отпускается около миллиарда упаковок лекарств. Оборот превысил миллиард долларов в 2004 году.
Основные проблемы в области ИТ: низкая степень интеграции систем, не документированность основных бизнес-систем. Сложности при прохождении аудита и децентрализованная архитектура ИС. Филиалы (региональная структура филиалов — от Калининграда до Владивостока) имеют свои базы данных, собственные информационные системы, что отрицательным образом влияет на уровень стандартизации бизнес-процессов и соответственно контроля процессов филиалов.

Какие функциональные области вы покрываете? Проводили ли вы реинжиниринг бизнес-процессов?

У нас выделено около трехсот бизнес-процессов в восьми функциональных областях, ведется актуальный процессный указатель, каждый процесс имеет своего владельца-эксперта. Это маркетинг, управление продажами, выполнение заказов, снабжение, управление запасами, финансы, планирование и прогнозирование, а также обслуживание клиентов. Больше всего процессов в области управления запасами (для нас главный производственный процесс), а также в управлении финансами.

Особенности бизнеса компании таковы, что в финансовой подсистеме мы внедряем параллельно три вида учета: управленческий по МСФО, бухгалтерский РСБУ, налоговый. В сбыте у нас высокий уровень конкуренции, поэтому нужны сложные сбытовые модели для разных сегментов рынка. Требуется высокий уровень сервиса с точки зрения своевременности поставки, отсутствия проблем с товаросопроводительными документами, а также по точности исполнения заказа. В логистике функционирует централизованная система снабжения и планирования запасов филиалов, обязателен посерийный контроль качества, поскольку мы торгуем фармацевтическими препаратами, и у нас каждый препарат получает сертификат соответствия. Кроме всего прочего существуют процессы таможенного оформления поставок, ведь около 80% оборота приходится на импортные лекарства.

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

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

И каким образом вы увязывали стандарты на бизнес-процессы, предлагаемые ERP, и реальность, в которой действует бизнес?

Стандартная функциональность Oracle E-Business Suite, которую нам старательно навязывали в течение этапа проектирования наши подрядчики, в значительной степени не удовлетворяет требованиям нашей бизнес-практики, особенно по функциональной производительности ряда бизнес-процессов, и не отражает требований российского законодательства в области фармацевтической дистрибуции. Это привело к значительному объему кастомизации системы. При внедрении системы в нашем филиале было сделано более ста программных доработок, на головном предприятии - еще триста. Для сравнения: у нас недавно в гостях был ведущий шведский дистрибьютор, так в этой компании при внедрении системы выполнили семь разработок и очень удивлялись, почему у нас так происходит. Заметный контраст. С другой стороны, производительность их складов отличается от нашей более чем на порядок. В меньшую сторону.

Что было самым сложным при проектировании бизнес-процессов?

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

В чем еще особенности вашего проекта?

Мы применяем методику внедрения Oracle AIM, основные шаблоны и документы которой были адаптированы к особенностям проекта в ЦВ "Протек" нашими партнерами Tops BI и Oracle. Принципиальным было решение развертывать систему начиная с филиалов.

Кроме того, мы предъявляем высокие требования к производительности складских процессов. В среднем филиал у нас исполняет от пяти до десяти тысяч строк заказов в сутки, крупные филиалы выполняют более двадцати тысяч строк, а на головном предприятии к моменту запуска системы в сутки будет выполняться почти 200 тысяч строк заказов. По нашим прогнозам, к 2008 году система должна будет обрабатывать в целом по компании один миллион строк заказов в сутки. Это очень большие объемы операций даже для такой системы, как Oracle E-Business Suite, и поэтому критерий транзакционной производительности для нас жизненно важен.

Есть и другие нюансы, связанные с применением методологии внедрения Oracle. В соответствии с ней мы тестируем программные разработки и проводим интеграционное потоковое тестирование системы. Кроме этого, ведется тестирование системной производительности критичных бизнес-процессов в соответствии с аппаратными средствами, тестируем патчи. При внедрении в филиалах у нас не было этапа опытной эксплуатации (это не предусмотрено методологией). Мы сразу переходили полностью на новую систему, выключали старые системы и запускали новые бизнес-процессы. В результате приходилось сталкиваться с определенными проблемами. Теперь этот порядок изменен. При внедрении системы на головном предприятии компании будет проводиться опытная эксплуатация системы в течение трех месяцев, старая и новая системы будут работать параллельно на ограниченном объеме операций.

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

Прежде всего это недостаток человеческих и временных ресурсов. По нашим оценкам, соотношение затрат времени на тестирование и проектирование должно быть примерно 1:1, то есть если вы проектируете систему полгода, значит, полгода вы должны ее и тестировать. При запуске системы на первом (пилотном) филиале интеграционное потоковое тестирование (в котором выявляется больше всего ошибок и нестыковок процессов между собой) проходило фактически в течение только одного месяца, что не позволило качественно протестировать систему и устранить ошибки.

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

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

В заключение скажу, что проблема усугубляется сложностью автоматизации тестирования Oracle E-Business Suite. Система просто не предназначена для автоматического тестирования функциональности. В результате затраты человеческих ресурсов на прогоны потоков действительно значительны, поэтому при выборе системы необходимо обращать внимание на то, как вы будете ее тестировать, при чем не только при запуске в эксплуатацию, но и позже, когда придется улучшать систему и исправлять ошибки

Каким образом принималось решение о запуске системы?

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

Известно, что в вашей компании практикуются методы детальной, в том числе численной оценки и производительности оборудования, и эффективности труда сотрудников…

Иметь четкий набор критериев успешности проекта крайне важно с точки зрения операционной эффективности. Этот набор носит довольно индивидуальный характер для каждой компании. Не обязательно эти критерии все окажутся экономическими, они могут быть и качественными. Надо понимать, что успех проекта может трактоваться с разных точек зрения: с точки зрения спонсора, проекта, с точки зрения руководства проекта, с точки зрения подрядчиков или наших клиентов. Также нужно принять во внимание точку зрения конечного пользователя и линейного менеджера, который работает непосредственно с системой.

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

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

Есть и критерии в области финансов. Это временные нормативы закрытия основных учетных моделей системы, наличие и работоспособность процедур выверки данных основных модулей учета и Главной книги, временные нормативы формирования основных финансовых отчетов. Наиболее отлаженный компонент пока - как раз финансовый. Здесь серьезных проблем нет, эти модули успешно работают во всех филиалах.

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

Интегральная оценка удовлетворенности пользователей - это качественная оценка "хорошо" или "плохо". Здесь важны и интерфейсы, с которыми имеет дело пользователь, и наличие инструкций по работе пользователей с различными полномочиями. Мы также фиксируем скорость формирования необходимой управленческой отчетности. Были такие случаи, когда коммерческий директор филиала запускал анализ задолженности, который ранее формировался в течение пяти или трех минут, а теперь такой отчет может отнять более получаса, причем потребуется ручная работа. Хотя это полностью соответствует методологии и критериям компании Oracle, коммерческий директор филиала не может быть доволен. Для его работы с клиентом нужны оперативные данные, и в результате эффективность работы топ-менеджмента снижается. Вопрос о том, насколько внедренная система обеспечивает управленческий процесс, тоже становится ключевым. Часть отчетности филиалов мы уже можем получать в головном предприятии, что позволило снизить нагрузку на филиалы. Следующий критерий - качество интеграции с другими приложениями. Мы оцениваем количество ошибок в этих интерфейсах. К сожалению, Oracle E-Business Suite - далеко не открытая система с точки зрения интерфейсов, бывает, что сделать их или невозможно - тогда приходится использовать двойной ручной ввод, или весьма сложно и трудоемко.

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

Насколько точными оказались ваши оценки производительности аппаратной части?

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

Каково текущее состояние проекта и ваши дальнейшие планы развертывания ERP?

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

Кроме того, идет подготовка к запуску головного предприятия в Москве. Здесь мы отказались от практики "большого взрыва", будем использовать по-модульный подход. Это хотя и дороже, но значительно снижает риски падения качества нашего сервиса и потери лидерства на рынке. Принято решение отказаться от внедрения модуля управления складом (WMS) на головном предприятии. Это связано с тем, что больше половины всех проблем в филиалах при внедрении было связано именно с этим модулем, а ведь для нас склад является основным производственным ресурсом. Именно поэтому при внедрении на головном предприятии руководство приняло решение не использовать этот модуль. Для нас самая приоритетная цель - быть лидером на рынке. И хотя сначала мы не зафиксировали ее отдельным пунктом в целях проекта (это разумелось как бы само собой), при возникновении противоречий решение было принято в пользу сохранения лидерства. Поэтому сейчас проектируются интерфейсы с собственной складской системой.

С мая 2005 года у нас будет запускаться функциональное планирование цепочки поставок и прогнозирования. С июня планируется запуск шести филиалов после оптимизации системы и достижения ими принятых критериев. Далее до конца года мы запланировали запуск блока финансовых модулей. Мы продолжаем готовиться к внедрению остальных запланированных модулей в 2006 году.

Что с вашей точки зрения необходимо, для успеха проекта внедрения ERP-системы?

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

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

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

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