Телекоммуникационный оператор не выпускает материальной продукции и не закупает сырья. Какую роль может (и должна) играть в его деятельности ERP‑система? Об этом мы беседуем с вице-президентом по бизнес-процессам и ИТ компании «Акадо» Федором Красновым.

Intelligent Enterprise: Для промышленного предприятия ERP‑система — центральная, либо одна из центральных ИТ‑систем. Но в сфере телекоммуникаций главную роль играют другие решения: биллинг, CRM‑система… Какое место должна занимать ERP‑система в ИТ-архитектуре телекоммуникационной компании?

Федор Краснов: Дей­ст­вительно, ERP‑система по своему назначению — это преимущественно система планирования ресурсов, а у телекоммуникационного оператора нет истощимых материальных ресурсов, нуждающихся в возобновлении. Однако есть другие. Как всякое предприятие, мы должны управлять человеческими и финансовыми ресурсами. Именно для учета этих ресурсов, как правило, и используются ERP‑системы в телекоме. И это далеко не все.

Безусловно, у телекоммуникационной компании есть задача учета основных средств. Основное средство всякой телекоммуникационной компании — сеть, ее необходимо инвентаризовать, при этом мы используем систему инвентаризации. Для телекоммуникационных компаний разработан стандарт на бизнес-процессы e-TOM, к которому мы постоянно обращаемся. И система инвентаризации там занимает подчиненное положение, явно не первостепенное по важности. Замечу, что возможны и иные подходы — модуль инвентаризации может находиться в биллинговой системе и обеспечивать учет специфических ресурсов для предоставления доступа в Интернет, таких как IP-адреса. В нашем подразделении, занимающемся кабельным телевидением, инвентаризация примыкает к операции активации услуги. Организация доступа к услуге и учет оборудования доступа — очень близкие темы, их вполне можно объединить в рамках специализированного решения, и это часто делается.

Итак, инвентаризация в той ее части, которая касается оборудования абонентов, примыкает к биллингу. А в той части, которая относится к сети, пожалуй, ближе к бухгалтерским системам. Учет этих средств разумно вести на базе ERP‑системы или аналогичного решения. Это и определяет место ERP‑системы в ИТ-архитектуре оператора. Наконец, в редких случаях внедряется специализированная система инвентаризации ресурсов. Примером может служить МТТ, где используется Granite Inventory, которая работает с сетью как с активом, и данные инвентаризации поступают из нее в бухгалтерские и прочие учетные системы.

Расскажите подробнее, как используется ERP‑система для оптимизации материальных ресурсов оператора. Какие есть здесь особенности, и как используются инструменты ERP‑системы?

В «Акадо» за последний год сложилась очень интересная ситуация: возникла задача, для решения которой мы сначала применили классические методы MRP, а затем, углубляя свое решение, перешли к MRP2 и далее к ERP, то есть прошли весь путь эволюции подобных систем.

Задача следующая. У нас есть абонентское оборудование — приставки (STB), которые подключаются к телевизору, — и мы сдаем их в аренду клиентам при предоставлении услуг. В докризисное время мы учитывали затраты на эту аппаратуру как инвестиции в сеть. Когда сдали устройство — выросла стоимость сети, а дальше идет амортизация этого оборудования. Иначе говоря, подход аналогичный, например, кабельному хозяйству, хотя, по сути, это совершенно другой процесс.

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

Мы стали решать эту проблему и посмотрели на процесс, связанный с клиентским оборудованием более детально. Оборудование, которое мы раздали, находилось у клиентов, но не всё — ведь существует отток клиентов, и при прекращении договора устройство сдается и возвращается на склад, после чего восстанавливается и может быть передано следующему пользователю. Таким образом, мы оказались перед классической задачей MRP — просчитать объемы складских запасов и закупок оборудования для обеспечения заданного объема выпуска продукции.

Мы начали с очень простой модели — попробовали учесть отток абонентов и возврат оборудования. Возврат оборудования у нас происходил, но никто не занимался им как важным процессом. Есть модель оттока абонентов, из этого оттока мы сможем собрать, предположим, 90% оборудования, а восстановить сможем, опять же, 90% собранных устройств (какие‑то окажутся неисправными). Восстановленные устройства будут добавляться к запасу, имеющемуся на складе, так что мы сможем просуществовать дольше, чем показывал первый расчет. В результате этого анализа крайний срок следующей закупки оборудования несколько отодвинулся.

Затем мы стали оценивать потребность в ресурсах для восстановления — в людях, оборудовании, специальных проветриваемых помещениях. Добавили количество монтажников, нужное, чтобы деинсталлировать оборудование — выехать, обзвонить, собрать. Учли особенности процесса: монтажники ездят на «Газелях», которые берут шесть человек, и т.д.

То есть вы перешли к следующей ступени алгоритма — балансировке мощностей…

Да, мы подключили HR‑де­партамент, выяснили тонкости оптимизации работы монтажников. Постепенно все больше и больше людей в компании вовлекалось в проект. Все понимали, что его цель — максимально отодвинуть следующую закупку абонентского оборудования. Это был общий процесс поиска решений: он объединял людей, и всякий находил в нем свое место.

И мы продвинулись довольно далеко: усовершенствовали учет брака и ремонта, научились планировать не только от новых абонентов, а и от заявок на подключение, стали более точно ставить условия закупочному подразделению. К нам стали по‑другому относиться производители оборудования — на новый уровень поднялась дисциплина закупок, и партнеры это заметили. Есть оптимальный размер закупочной партии, и существует формула, позволяющая его рассчитать. Я не могу сказать, что у нас сейчас реализован принцип just-in-time, но нам по крайней мере удалось объяснить кладовщику, что любое складирование — потеря.

Основная наша задача сейчас — это поиск резервов эффективности, и здесь, на мой взгляд, их стоит поискать.

Мы говорим о решении задач оптимизации материальных запасов как о процессе и методологии. А какими ИТ-инструментами это было поддержано?

Первые полгода инструментальная поддержка была минимальной: мы работали с маленьким файлом Excel, который потом разросся. Затем, когда нам стало понятно, что нужно, — процесс уже поставлен, проблемы решены, — мы занялись автоматизацией.

Для поддержки этих задач новых систем не нужно — ведь какая‑то ERP‑система у всех уже есть. И мы, исходя из этого убеждения, находили, где и чем мы можем воспользоваться, и связывали эти инструменты с соответствующими информационными цепочками. Соответствующее решение было создано буквально за пару недель: дописали кое‑что в нашей ERP‑системе Microsoft Navision, кое‑что — в ее интеграции с биллинговой системой, добавили в SAP Business Objects несколько отчетов. Когда задача решена на содержательном уровне, автоматизировать ее становится проще.

Тем не менее вы сейчас задействуете небольшую часть всего функционала ERP‑систем. Даже такая система, как Microsoft Navision, используется совсем не полностью. Какие еще алгоритмы автоматизированного расчета из арсенала ERP‑системы могут быть вам полезны?

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

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

Далее: на одного монтажника у нас приходится в день N заказов. Почему именно N, а не, скажем, 2N? Что нужно сделать, чтобы удалось обслужить 2N заказов, — куда подвезти монтажника, какие инструкции ему дать, каким оборудованием снабдить? Сейчас пытаемся применить процессный подход — посчитать, условно говоря, эффективность одной заявки. Мы платим такую‑то зарплату и такие‑то премии, а как они разделяются по процессам в зависимости от услуг, которые мы подключаем, и категорий абонентов?

Когда для процесса уже существуют какие‑то показатели, можно заниматься их улучшением. Но процесс остается цельным — мы не разрушаем его, а совершенствуем его элементы.

Процесс учета возвратов, ремонтов и брака, который вы описываете, совсем не прост. Вы делали формальное описание процесса в каком‑либо инструментарии, или, на ваш взгляд, допустимо упрощенное описание?

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

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

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

Вы уделяете отчетам очень много внимания…

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

Другое дело, что в отчете, естественно, собраны нужные данные. На самом деле специа­листы часто недооценивают искусство составления правильных отчетов — они считают, что наличие данных само по себе гарантирует их понимание. На самом деле необходимо еще отсутствие лишних мелочей — они затрудняют понимание. К примеру, когда у тебя больше миллиона рублей, незачем проставлять два нуля после запятой, а если абонент заказал у нас все шесть пакетов тематического ЦТВ, неразумно их перечислять — проще написать «все».

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

Идея очевидная, но у нас только недавно появилась для этого возможность — раньше все системы, связанные с ГИС, стоили неоправданно дорого. А сейчас стали доступны системы на свободной основе, такие как Google Maps, и мы интегрируем их данные с нашими системами.