Самописная help desk система — плюсы и минусы самостоятельной разработки

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

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

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

Так ли это?

Давайте подсчитаем плюсы и минусы самописных решений.

Плюсы самописной help desk системы

• Полный контроль логики решения. Являясь постановщиками задачи, мы можем поддержать любые необходимые нам бизнес-процессы (даже узко специализированные) и автоматизировать любую экзотику.
• Нет лишних функций. Поскольку решение не ориентировано на массовый рынок, выбирать наиболее популярные функции и отбрасывать непопулярные не придется. Реализуем только нужное, вообще не трогаем не нужное и не переплачиваем за разработку, результаты которой нами не востребованы.
• Нет лишних элементов интерфейса и бизнес-логики. Мы можем сделать такой интерфейс, что в нем наши бизнес-процессы будет соблюдать даже неопытная сотрудница первой линии (специально для нее сделаем экран с одной кнопкой). Конечно, в некоторых сторонних решениях, например, в Окдеск, есть отключаемые модули, но они не всегда позволяют убрать с экрана все ненужное (в требуемой конфигурации), что приводит к путаннице.
• Появление новых функций строго в соответствии с собственными пожеланиями. Курс развития продукта (в нашем случае — help desk) не контролируется его пользователями. Всегда существует вероятность того, что выбранное решение неожиданно пойдет в противоположном направлении. А при собственноручной разработке такое попросту невозможно.
• Отсутствие риска недобросовестного поставщика или пропажи с рынка компании, занимающейся разработкой. Покупая решения, мы подписываемся на долгосрочные взаимоотношения, рассчитывая на техническую поддержку и обновления. Но рынок, тем более российский, — штука непредсказуемая. Что если производитель решения просто уйдет с него? Как, например, это сделали Zendesk и прочие зарубежные help desk системы? При самостоятельной разработке создатель системы будет существовать ровно столько, сколько и ее потребитель, поскольку это (условно) одно лицо.
• Низкая стоимость. При использовании самописного решения отсутствуют капитальные затраты на развертывание (в части покупки продукта), а также операционные — на подписку. Но важно понимать, что этот плюс актуален только в том случае, когда есть разработчики и постановщики задач. И выгода здесь — условна, поскольку сотрудники и их труд стоят денег. Даже если в штате есть программист, часы его работы, фактически, оплачены через ФОТ + налоги. Меньше ли это абонентской подписки? Далеко не всегда. Пара месяцев работы одного только программиста вряд ли обходятся работодателю дешевле 200 тысяч.
• Возможность выбора необходимой архитектуры. У каждой компании свои представления, как необходимо внедрять решение. Кто-то хочет веб, кто-то — наоборот. Аналогично можно выбрать используемые технологии (framework, языки программирования и т.д.).

Создание тикет-системы собственными силами — это как самостоятельный пошив костюма.

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

Однако, навыки, время и понимание — слишком уж редкое сочетание.

Поэтому тех, кто шьет себе одежду совсем не много.

Минусы самописной help desk системы

• Нужен целый спектр компетенций. Даже если предположить, что у нас есть разработчик с требуемыми навыками, для создания полноценного решения нужны системный аналитик, собирающий требования к решению, бизнес-аналитик, способный описать процессы, дизайнеры интерфейса, тестировщики, архитектор и т.п. В этом списке одни отвечают за работоспособность решения, а другие — за его будущее масштабирование. И в корпоративном сегменте нельзя чем-то жертвовать.
• Экспертиза нужна не только в разработке ПО, но и в «проблематике» самой компании. Изнутри бизнеса сложно увидеть перспективы (и, тем более, перспективные требования к ИТ-инфраструктуре) на 5-10 лет вперед, поэтому самописные решения чаще всего создаются в соответствии с текущими нуждами компании и сдерживают дальнейшее развитие процессов.
• Нужно выстроить процесс разработки. Придется нанимать сотрудников, ставить им задачи, следить за исполнением и мотивировать. Гляньте видеозаписи профильных конференций программистов — это чуть ли не самая сложная задача, с которой сталкиваются специализированные конторы.
• Придется разворачивать инструменты для разработки — среду разработки, систему контроля версий и т.п. А это дополнительные затраты на поддержку собственной ИТ-инфраструктуры.
• Решение придется самостоятельно поддерживать и дорабатывать под изменяющиеся требования. В этом процессе надо не только «не сломать» то, что уже работает, но и не наплодить «костылей». Причем, саму возможность дальнейшей доработки необходимо учесть еще на этапе подготовки плацдарма (см. предыдущий пункт). Если не хранить ту же постановку задачи или версии модулей, потом в системе черт ногу сломит. В какой-то момент окажется, что искомый модуль писал уже уволившийся «непонятно кто». Как он работает и можно ли его видоизменить, не ясно.
• Высокая стоимость разработки и поддержки нескольких платформ, в частности, мобильные приложения. Расширение списка поддерживаемых решением платформ требует как минимум разработчиков с соответствующими компетенциями. Где их достать? Заказывать отдельно мобильное приложение у сторонних компаний — дорого (от 300 тыс. рублей); а нанимать разработчиков для его создания под собственную систему — значит повторять описанные выше сложности, связанные с наладкой рабочего процесса. И все это бессмысленно, поскольку проект, скорее всего, будет разовым.
• Отсутствие документации или дополнительные затраты на ее создание на этапе разработки. Также хотелось бы отметить в целом проблемы на этапе внедрения, поскольку опыта других компаний перед глазами нет. Со своим продуктом разработчик всегда первопроходец.
• Медленная реакция на рыночные изменения. Продукты для автоматизации каких-либо бизнес-функций должны эволюционировать вместе с бизнесом. Но чтобы воплотить какие-то изменения в жизнь, всю «машину» доработки придется разворачивать в нужном направлении. Даже осознав и внятно сформулировав бизнес-требования, владельцы бизнеса получат работоспособное решение далеко не сразу.

Даже поверхностный анализ показывает, что минусов больше.

Писать самостоятельно или купить готовое решение?

Стоит отметить, что плюсов может стать еще меньше, если грамотно подойти к выбору сторонней системы и сравнивать не с абстрактным, а с вполне конкретным продуктом.

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

Конечно, соблазн велик писать индивидуально под себя, делать из системы help desk весомое конкурентное преимущество.

И подобные мысли возникают у многих.

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

Полезные материалы

Дважды в месяц о развитии и автоматизации сервиса, техподдержки и выездного обслуживания.

 

Подписаться

Нажимая на кнопку «Подписаться», вы даете согласие на обработку своих персональных данных.

Кирилл Федулов

Сооснователь и директор по развитию Okdesk. Около 10 лет проработал в компании Naumen, где занимался внедрением ITSM и service desk систем в крупнейших российских компаниях: Полюс, Тинькофф, ЛСР и др. Эксперт в области организации и автоматизации процессов техподдержки, сервиса и выездного обслуживания