Лого vc.ru

«Сами разберемся»: Почему не нужно внедрять сложные продукты своими силами

«Сами разберемся»: Почему не нужно внедрять сложные продукты своими силами

Роман Артюх, исполнительный директор компании «Латера» (разработчик биллинга «Гидра») написал для vc.ru колонку о том, почему компаниям не стоит внедрять сложные продукты своими силами.

Поделиться

В одном из предыдущих материалов на «Хабрахабре» мы рассказывали о том, почему решение заняться самостоятельной разработкой сложной системы вроде биллинга может привести к проблемам.

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

В чем проблема

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

Именно поэтому самостоятельное внедрение такой системы почти гарантированно приведет компанию к ситуации, когда желание сэкономить в итоге выливается в дополнительные траты.

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

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

В таких конкурентных сферах, как телеком, любая задержка может серьезно повредить бизнесу — конкуренты не спят и активно развивают свои услуги, предлагая клиентам новые интересные условия.

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

Пример из сферы биллинга — у одного физического абонента оператора связи может быть несколько договоров, к примеру, для разных квартир, или услуг. В нашем биллинге «Гидра», когда мы знаем, что мы имеем дело с одним и тем же Иваном Ивановым, все данные по нему сводятся в одну сущность «клиент», но есть и системы, где все не так. В нашей практике были случаи, когда клиенты, переходившие с таких продуктов просили сделать из одного такого Ивана Иванова несколько абонентов — по одному на каждый договор или услугу (интернет, телевидение, телефония и так далее).

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

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

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

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

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

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

Поработать все равно придется

Политика «вот вам деньги, сделайте хорошо» в случае внедрения сложных технологических продуктов может перечеркнуть все выгоды от передачи проекта подрядчику. Внедренцам нужно помогать — консультировать их по конкретным вопросам, связанным с бизнесом, предоставлять доступ к необходимым для работы системам. А некоторые работы, такие как перенастройка сетевого оборудования или выгрузку данных из устаревшего самописного биллинга, подрядчику зачастую (но не всегда) отдавать просто невыгодно.

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

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

Что делать: проектный подход

Опыт более 100 проведенных нами внедрений собственного биллинга «Гидра» позволяет сделать еще один не самый приятный вывод. Даже в том случае, когда руководство компании настроено максимально конструктивно и готово инвестировать в новую систему и ее внедрение, далеко не всегда это мотивирует технических специалистов этой компании.

В результате большинство заказчиков не может управлять проектом внедрения — перед его стартом, всем кажется, что нужно будет активно контролировать подрядчика (то есть нас), но во многих случаях, наоборот, нам приходится контролировать заказчика. Это происходит не потому, что заказчики ленивые или плохие, а по объективным причинам — у оператора связи нет «лишних» сотрудников, все они загружены текущими задачами, а внедрением нового биллинга им приходится заниматься чуть ли не сверхурочно.

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

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

Многократно столкнувшись с подобными ситуациями, мы пришли к необходимости переформатирования работы по внедрению биллинга. Теперь мы полностью берем на себя управление такими проектами на себя — для этого в компании есть выделенный сотрудник, который ведет всю информацию в системе управления проектами Teamwork.

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

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

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

Присылайте колонки, соответствующие требованиям редакции, на secret@vc.ru

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

Роман, спасибо за интересную статью и кейс.

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

0

Возможность комментирования статьи доступна только в первые две недели после публикации.

Сейчас обсуждают
Алексей Nein

Если это отсылка к 2011 году, то это оооочень смешно))) не сразу понял.

Видео: Герман Греф в «костюме инвалида» в отделении «Сбербанка»
0
Mike Kosulin

Утопично искать команды. Если только на прототипировании сфокусироваться, то еще ок.

Kriya AI — сервис по поиску удалённой команды для запуска стартапа
0
Mike Kosulin

Скорее всего по определённым тематикам происходит скорринг источников. Чем больше ограничений задается, тем проще выявить наиболее надежные источники информации.

«Яндекс» создал платный поисковик информации для бизнеса
0
Тимур Даянов

Цитирую:
В любых делах при максимуме сложностей
Подход к проблеме все-таки один:
Желанье — это множество возможностей,
А нежеланье — множество причин.

Эдуард Асадов

Бывшие сотрудники «Ленты.ру» и «Пикчер» запустили издание для родителей «Нет, это нормально»
0
Pavel Bokarev

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

Бывшие сотрудники «Ленты.ру» и «Пикчер» запустили издание для родителей «Нет, это нормально»
−3
Показать еще