Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.
В одном из предыдущих материалов мы рассказывали о том, почему решение заняться самостоятельной разработкой сложной системы вроде биллинга может привести к проблемам. Вся беда в том, что и просто купить готовый коробочный продукт у его разработчиков еще недостаточно для того, чтобы гарантировать себе безоблачное будущее. Нельзя просто так взять и внедрить сложную систему — в итоге каждый проект превращается в настоящий квест с непредсказуемым финалом.
В чем проблема
Внедрение таких сложных продуктов, как биллинг — это крайне непростой процесс. Несмотря на то, что система может называться «коробочной», по факту все компании, ее использующие, довольно серьезно отличаются — мы говорим главным образом об операторах связи. Это значит, что типовых решений для возможных проблем нет — каждый раз процесс может пойти по совершенно новому, уникальному пути.
Именно поэтому самостоятельное внедрение такой системы почти гарантированно приведет компанию к ситуации, когда желание сэкономить в итоге выливается в дополнительные траты.
Посудите сами, даже при наличии качественной документации, на ее разбор специалистам компании — покупателя системы потребуется большое количество времени. Они могли бы потратить его на свою непосредственную работу. То есть бизнес начинает нести убытки уже на этом этапе.
Очевидно, что если специалист делает какую-то операцию регулярно, то скорость работы в таком случае повышается. Внедрение биллинга не попадает в разряд регулярных операций, потому что такие системы выбираются на годы вперед. Это значит, что на развертывание купленного решения уйдет куда больше времени, чем если бы этим занимались его специалисты, осуществившие большое количество внедрений этого продукта. В таких конкурентных сферах, как телеком, любая задержка может серьезно повредить бизнесу — конкуренты не спят и активно развивают свои услуги, предлагая клиентам новые интересные условия.
Еще один важный момент — идеология сложных систем, которые решают одну и ту же задачу, в реальности может очень серьезно отличаться. В итоге это еще больше усложняет миграцию — часто к новому инструменту применяют принципы работы старого. Ничего хорошего из этого, как правило, не выходит.
Пример из сферы биллинга — у одного физического абонента оператора связи может быть несколько договоров, к примеру, для разных квартир, или услуг. В нашем биллинге «Гидра», когда мы знаем, что мы имеем дело с одним и тем же Иваном Ивановым, все данные по нему сводятся в одну сущность «клиент», но есть и системы, где все не так. В нашей практике были случаи, когда клиенты, переходившие с таких продуктов просили сделать из одного такого Ивана Иванова несколько абонентов — по одному на каждый договор или услугу (интернет, телевидение, телефония и т.п.)
Это ломает всю логику работы системы — корректно вести статистику и строить отчеты по таким «раздвоенным» или даже «растроенным» абонентам очень сложно. В итоге заказчик просил доработки системы, которые могли бы как-то облегчить возникшие проблемы — но их бы не было вообще, если бы система изначально внедрялась по предусмотренной схеме.
Наконец, никто не застрахован от ошибок, а при внедрении сложной системы их просто невозможно избежать. А это значит, что даже потратив много времени, нервов и сил, компания только входит в зону турбулентности, где проблемы могут случиться в любой момент. Некоторые ошибки проявляются не сразу. Поэтому может возникнуть ситуация, когда сложная система куплена, самостоятельно настроена и запущена в боевом режиме без всяких проблем. Но спустя какое-то время случается внезапная катастрофа.
Учитывая тот факт, что тот же биллинг — это одна из ключевых ИТ-систем бизнеса, без которой невозможно корректное обслуживание клиентов и списание с них платы за услуги, даже небольшая ошибка может привести к значительным последствиям.
К примеру, в какой-то момент может быть заблокировано оказание услуг определенному количеству пользователей из-за ошибки в оформлении тарифного плана или подписок. В случае с программами лояльности ошибка может проявиться и через несколько месяцев — старые пользователи не обрадуются ошибочной отмене своих скидок или подписок на дополнительные услуги. При внедрении с помощью специалистов разработчика системы такие типичные ошибки будут найдены и нейтрализованы.
Кроме того, сэкономить и передать задачу по внедрению не разработчикам, а внешним специалистам-аутсорсерам не всегда возможно в принципе. К примеру, на российском рынке биллинга таких независимых профессионалов просто нет, и даже не все разработчики биллинговых систем предлагают заказчикам помощь в их развертывании. Именно поэтому, тот факт, что разработчики помогают заказчикам внедрять созданную систему должен обязательно учитываться при выборе системы из разных вариантов (на что еще следует обращать внимание мы писали здесь).
Кажется, что возможные проблемы понятны, и все, что нужно сделать — просто привлечь разработчиков, чтобы все точно прошло как по маслу. К сожалению, этого тоже недостаточно.
Поработать все равно придется
Политика «вот вам деньги, сделайте хорошо» в случае внедрения сложных технологических продуктов может перечеркнуть все выгоды от передачи проекта подрядчику. Внедренцам нужно помогать — консультировать их по конкретным вопросам, связанным с бизнесом, предоставлять доступ к необходимым для работы системам. А некоторые работы, такие как перенастройка сетевого оборудования или выгрузку данных из устаревшего самописного биллинга, подрядчику зачастую (но не всегда) отдавать просто невыгодно.
Если это игнорировать, специалисты не смогут сделать свою работу. К тому же всевозможные заминки будут приводить к пустой трате времени, и возникающей вполедствии спешке при приближении сроков сдачи проекта — в итоге количество ошибок будет расти.
То есть многие плюсы от привлечения разработчиков к внедрению созданного ими решения просто сойдут на нет. Чтобы этого избежать усилий одного заказчика недостаточно, сами разработчики должны соответствующим образом организовать процесс внедрения.
Что делать: проектный подход
Опыт более 100 проведенных нами внедрений собственного биллинга «Гидра» позволяет сделать еще один не самый приятный вывод. Даже в том случае, когда руководство компании настроено максимально конструктивно и готово инвестировать в новую систему и ее внедрение, далеко не всегда это мотивирует технических специалистов этой компании.
В результате большинство заказчиков не может управлять проектом внедрения — перед его стартом, всем кажется, что нужно будет активно контролировать подрядчика (то есть нас), но во многих случаях, наоборот, нам приходится контролировать заказчика. Это происходит не потому, что заказчики ленивые или плохие, а по объективным причинам — у оператора связи нет «лишних» сотрудников, все они загружены текущими задачами, а внедрением нового биллинга им приходится заниматься чуть ли не сверхурочно.
В итоге проекты далеко не всегда заканчивались в срок. Когда договор на внедрение только подписан и до момента запуска системы еще несколько месяцев, соблазн отложить работу в этом направлении на потом, а сейчас заняться чем-то более актуальным. Это выливается, к примеру, в то, что мы могли месяцами ждать, пока инженеры заказчика подготовят нам тестовый стенд для «заливки» биллинга и его настройки. Сначала нам неделю не дают виртуальную машину, потом мы не можем к ней подключиться из-за не открытых портов, затем система перезагружается и доступ к стенду опять пропадает — на решение столь «важной» задачи может уходить до месяца.
В итоге, когда сроки начинают поджимать, на специалистов компании-заказчика, как правило, начинают давить руководители. Сдвинуть сроки перехода на новый биллинг часто нельзя, поэтому после потраченных впустую месяцев за последние пару недель нужно нагнать все отставание.
Многократно столкнувшись с подобными ситуациями, мы пришли к необходимости переформатирования работы по внедрению биллинга. Теперь мы полностью берем на себя управление такими проектами на себя — для этого в компании есть выделенный сотрудник, который ведет всю информацию в системе управления проектами Teamwork.
В ней наглядно показаны все необходимые этапы проекта, задачи, которые должны быть выполнены, и те участки работы, которые будут разблокированы после этого. Также указаны ответственные за решение стоящих задач с обеих сторон.
Таким образом, на нас лежит задача по отслеживанию всех этапов работ, корректном логировании проведенных работ и планировании грядущих задач, которые нужно сделать самим и поставить перед специалистами заказчика.
В итоге эффективность работы инженеров двух сторон значительно возрастает — сотрудники компании-разработчика лучше понимают, что и когда им нужно сделать по проекту, а представителям клиента понятно, на каком этапе находится весь процесс. Таким образом потенциальные проблемы можно выявить еще до того, как они перерастут во что-то серьезное.
Другие статьи по теме ИТ-инфраструктуры:
- Проблемы биллинга: Что может пойти не так с самописным софтом
- Как повысить отказоустойчивость биллинга: Опыт «Гидры»
- DoS своими силами: К чему приводит бесконтрольный рост таблиц в базе данных
- Как организовать платную поддержку сложного продукта: Опыт «Гидры»
- Что еще влияет на инфраструктуру: Как обеспечить качество монтажа оборудования
