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

– Зачем подобные преобразования нужны бизнесу – какой мотив у интеграторов?

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

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

Переход к продуктовой разработке не только добавляет новые решения в портфель компании, но и позитивно влияет на нас самих, ведь мы можем предлагать более качественную автоматизацию, чем раньше. Появляются новые системы, роли и процессы. Разработка меняется, в результате создаваемое программное обеспечение становится отчуждаемым. К внутренним метрикам разработки ПО добавляется time to market (время с момента формирования идеи до выпуска готового продукта на рынок) и индексы удовлетворенности заказчика. Мы трансформируем собственное восприятие – когда делаем не просто софт для нашей компании, а для клиента, многое меняется. И на первый план начинают выходить другие вещи.

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

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

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

– Какие новые возможности компания рассчитывает получить при такой трансформации?

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

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

– Как происходит такая перестройка — какие шаги требуется предпринять компании?

Триггером для нас стал запрос со стороны рынка. Обмен знаниями в области функционирования компании привел к тому, что наш заказчик спросил, как ему получить часть этого «автоматизированного опыта».

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

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

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

– Сейчас у вас разработаны три продукта – какие они и как появились?

Начну с Телеграм-бота MyFellow Bot. Он был создан в связи с распределенной структурой компании – у нас шесть филиалов по всей стране и много людей, работающих удаленно. Есть внутренний портал, содержащий каталог услуг для сотрудников. Он находится в закрытом контуре корпоративной сети, и чтобы получить к нему доступ, специалисту, трудящемуся дистанционно, нужно использовать VPN. Кроме того, рабочие процессы могут продолжаться за пределами офиса – должно быть удобно максимально быстро формировать запросы к корпоративному сервису и согласовывать их.

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

– Так, а второе решение?

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

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

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

– А какой продукт замыкает тройку разработок?

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

Модульный подход к развитию продукта позволил расширить платформу процессами CRM, НR, Docflow, финансовой отчетностью. Концепция data-driven и инструменты аналитики позволяют принимать оперативные и квалифицированные решения на основе данных разнопланового анализа. За счет этого минимизированы субъективные факторы и ускорены многие процессы.