Сколько на самом деле стоит ИТ-система и почему разработка — это только вершина айсберга
Когда считаешь экономику ИТ-систем, очень легко отнести почти все расходы на первичную разработку. В этом есть своя логика: действительно, много ли может стоить интеграция и поддержка уже готовой системы по сравнению с зарплатами десятков недешевых специалистов, которые ее создавали в течение месяцев, а иногда и лет?
Но реальная практика такова, что первичная разработка или внедрение — как правило, лишь малая часть общей стоимости владения системой. Примерно так же, как видимая часть айсберга — всего лишь 10–15% от его реального размера. Этот принцип работает, когда система плохо спроекирована и неправильно интегрирована в существующую ИТ-архитектуру.
В этой статье поговорим о том, что на самом деле входит в Total cost of ownership (TCO) ИТ-системы и какие слагаемые нужно сразу закладывать в формулу, чтобы не оказалось, что «недорогая система» сжирает половину вашего ежегодного ИТ-бюджета. Будут примеры из опты KT.Team и мировой практики.
Из чего состоит полная стоимость владения ИТ-системы
При первом приближении затраты на владение ИТ-системой делятся на три большие группы.
1. Капитальные затраты
Самые очевидные. Сюда входит, во-первых, стоимость разработки или внедрения системы. Все те явные затраты, которые вы или ваш подрядчик можете подсчитать еще до старта проекта: проектирование системы, стоимость команды, стоимость дополнительной инфраструктуры, первоначальные лицензионные платежи, тестирование и разворачивание в прод.
Вторая и зачастую не менее затратная часть капитальных затрат — интеграция с существующими системами. На эту составляющую влияет состояние вашей архитектуры, используемые типы интеграций и наличие готовых API и коннекторов для интеграций между системами.
2. Операционные затраты
А вот с этого пункта начинаются расходы, которые сложнее прогнозировать на этапе разработки.
Поддержка и обслуживание. Система требует постоянного мониторинга, доработок, избавления от багов и регулярной поддержки.
По мере того как бизнес растет, вам неизбежно придется адаптировать систему под новые потребности, дорабатывать существующие интеграции и разрабатывать новые.
Например, у вас есть PIM-система, для которой вы собрали нужные шаблоны классов и карточек товаров. Но по мере роста бизнеса вы будете добавлять новые и новые классы товаров, новые шаблоны — а это замедлит вашу PIM и придется искать другие подходы. Так, например, было в одном из наших кейсов: чтобы обеспечить быстродействие системы при очень сложном каталоге, пришлось добавить дополнительный инструмент Pimcore.
Вы будете подключать новые каналы продаж: маркетплейсы, дилеров; будете добавлять новых поставщиков, будете перерабатывать взаимосвязи товаров, чтобы обеспечить их кросс-продажу. Всё это потребует доработок, а значит, подключения ИТ-команды, дополнительной инфраструктуры, интеграций, тестов и т.д.
3. Косвенные затраты
Об этом блоке затрат не принято говорить вслух, но часто именно он оказывается самым дорогим.
Представьте, что CRM-система, на внедрение и поддержку которой вы потратили десятки миллионов, в разгар Черной пятницы «отвалится» на три часа из-за перегрузки. Покупатели будут приходить к вам на сайт, набирать корзину и… попадать на бесконечно загружающуюся страницу оформления заказа. Всего за одну проваленную Чёрную пятницу вы потеряете столько же, сколько потратили на внедрение. Неприятный клиентский опыт, из-за которого вы потеряете постоянных покупателей, обойдется еще дороже. Это стоимость всего лишь трёхчасового простоя системы!
Еще один неявный риск связан с командой. Если система постоянно генерирует баги, если интеграции приходится постоянно перерабатывать, ваша команда всё время занимается однотипными и выматывающими задачами по поддержке. Спросите любого айтишника, является ли такая рутина пределом его мечтаний, и он ответит «нет».
Рутина выжжет вашу команду, сотрудники начнут уходить и на их место придется искать новых. Казалось бы, ротация в команде — дело нормальное. Но вместо стандартных 10–20% текучки рутина может привести к 30, 50%. А это значит: потерю ключевых сотрудников, затраты на поиск и обучение новых, потерю мотивации и эффективности у всей команды.
Прямым следствием высокой текучки станет и потеря знаний. Когда компанию покидают создатели системы или ключевые сотрудники, они часто не оставляют полной документации по системе. Тем, кто «унаследует» от них систему, придётся разбираться во многих нюансах самостоятельно — с риском сломать что-то в самый ответственный момент.
Как архитектура приложения и интеграций увеличивает TCO
Архитектура системы напрямую влияет на ее стоимость как на этапе разработки, так и в процессе дальнейшего обслуживания и масштабирования. Сложные и замкнутые системы могут затруднить внесение изменений, увеличивая риски простоев и затрат. Вот несколько признаков, по которым можно определить, что TCO системы будет высокой:
Система имеет закрытую архитектуру («черная коробка») или плохо задокументирована. Если доступ к отдельным частям системы ограничен, вносить изменения своими силами будет сложно или невозможно. То же касается и плохой документации кода: вам придётся долго разбираться, что делает каждый конкретный кусок кода, как он связан с другими функциями системы и какие последствия будут у небольшого изменения. Команда будет тратить много времени на каждое изменение, а в крайних случаях вам придётся обращаться к вендору за консультациями и доработками.
Система неправильно нарезана на сервисы: есть признаки низкой связности и высокой связанности (о связности и связанности читайте подробнее в одной из наших предыдущих статей). Представьте, что в одной системе у вас работают e-commerce-подразделение и бухгалтерия. Понятие «товар» может использоваться в контекстах обоих подразделений. Но у бухгалтерии «товар» — это артикул плюс цена. А e-commerce-отдел под товаром понимает тоже, что и клиент: кроссовки одной модели, но разных размеров с этой точки зрения — один и тот же товар в разных вариациях.
Чей контекст и язык системе будет «главным», а кому придется подстраиваться? Не нарушит ли это нормальных процессов продажи, учета, закупок? Каким образом придется согласовывать каждую, даже небольшую доработку — ведь изменение в одной части системы будет влиять на работу сразу нескольких подразделений? Сколько придется закладывать на тестирование и отладку во всех частях системы после каждого изменения?
Интеграции с существующими системами построены по принципу «точка–точка»: такой тип интеграций подразумевает сильную взаимную зависимость систем. Каждая переработка внутри любой из систем потребует переработки всех интеграций, которые с ней связаны. В реальности речь может идти о каскаде из десятков и сотен доработок.
Редкий стек технологий или риск вендор-лока: использование специфических технологий или решений или жесткая привязка к одному поставщику может привести к зависимости от конкретной команды разработчиков или к тому, что рано или поздно компанию ждут издержки из-за необходимости переезда на другие технологии.
В качестве примера плохого планирования можно привести Netflix. Когда компания трансформировалась из DVD-проката в онлайн-кинотеатр, она сделала ставку на монолитную архитектуру, но с ростом числа пользователей и увеличением объема контента система перестала справляться с нагрузкой. Из-за этого начались сбои, а пользоваться сервисом стало сложно из-за высокой задержки.
В итоге Netflix приняла решение о переходе на микросервисную архитектуру, что позволило значительно улучшить гибкость и скорость разработки. Каждый микросервис отвечает за отдельную функцию, что упрощает тестирование и обновление системы. Переход к новой архитектуре позволил Netflix быстро внедрять новые функции и оперативно масштабироваться, исходя из растущего запроса. Это решение также помогло снизить время отклика системы и повысить надежность сервиса в целом.
«Делать то, что нужно» — один из принципов сокращения TCO
Не делать лишнего в ИТ — почти непосильная задача. Просто загляните в свой бэклог и в список задач, которые передаете на испольнение ИТ-команде. Сколько там пунктов: 10, 100, больше? И все они важные…
Или это просто кажется?
Задач бесконечное множество, и чтобы ранжировать их по важности, нужно четко понимать свои ключевые ограничения.
С этим могут помочь несколько фреймворков.
Например, можно построить основной бизнес-процесс компании и разобраться, какие ограничения есть на каждом из этапов и сколько вы можете выиграть от устранения каждого из них.
Или построить карту гипотез, чтобы определить — какая из гипотез (какое внедрение) обеспечит вам максимальный экономический эффект.
Использование методов стратегического планирования позволяет не делать лишнего и не подменять смысл (изменение экономических метрик) количеством сделанных задач. Они же помогут понять, что действительно даст вам буст, а что только усилит влияние ключевых ограничений.
Например, компания – оптовый продавец запчастей для автомобилей хочет увеличить свой доход. Руководители отдела продаж считают, что разработка B2B-портала, на котором клиенты смогут оставлять свои заявки на подбор запчастей для автомобилей и техники, поможет вырастить доход.
Но перед тем, как вложить 10 миллионов в B2B-портал, стратегическая команда решила критично посмотреть на процессы. Построила ключевой бизнес-процесс компании, проанализировала существующие ограничения и поняла, что бутылочным горлышком сейчас стало не количество клиентов, а скорость подбора запчастей среди оригиналов и аналогов. Менеджеры просто зашиваются, выбирая в десятке таблиц, внутренних систем и внешних порталов варианты запчастей, чтобы сформировать КП для каждого клиента.
А значит, B2B-портал для клиентов не увеличит количество успешно реализованных заказов и станет в этой ситуации бесполезной тратой ИТ-бюджета. Нужно смотреть в другую сторону.
Обслуживание и масштабируемость
Хорошо спроектированная архитектура значительно облегчает поддержку и обслуживание системы. Например, системы с микросервисной архитектурой легче тестировать и обновлять, так как изменения затрагивают отдельные компоненты.
Масштабируемость системы также напрямую связана с архитектурой. Монолитные архитектуры всегда менее гибки. Из-за этого гораздо сложнее адаптировать их под меняющиеся требования компании.
Слабосвязанные архитектуры позволяют проектировать систему как набор независимых сервисов, которые взаимодействуют друг с другом через отдельные интерфейсы. Такая архитектура работает как конструктор: отдельные компоненты легко заменить или доработать, не затрагивая работу других частей системы.
Основные преимущества слабосвязанных архитектур:
Простота в обслуживании: ошибки и изменения в одном сервисе не затрагивают всю систему. В результате расходы на поддержание работы системы и внедрение новых функций гораздо ниже;
Масштабируемость: можно добавлять новые функции и сервисы без значительных изменений в других компонентах. Масштабировать и адаптировать систему к новым требованиям намного проще и дешевле;
Меньше рисков попасть в зависимость от команды: документированная и прозрачная структура системы позволяет онбордить новых специалистов быстрее и дешевле и снижает риск того, что проект станет непередаваемым.
К тому же слабосвязанные архитектуры снижают операционные расходы. Каждое обновление или доработка требует меньше усилий и времени, а риск возникновения критических ошибок снижается, потому что компоненты существуют отдельно друг от друга. Это позволяет избежать длительных простоев системы.
В исследовании (.pdf), проведенном для Международного симпозиума IEEE по вычислительному интеллекту и информатике, говорится: компании, которые перешли на микросервисную архитектуру, отметили увеличение скорости развертывания новых функций на 30-50%. Затраты на поддержку и обслуживание, в свою очередь, сократились на 20-40%. Более того, 70% организаций сообщили о повышении гибкости и способности адаптироваться к изменениям на рынке.
Несколько шагов, которые помогут оптимизировать TCO
- Проведите детальный анализ долгосрочных потребностей бизнеса ещё на этапе планирования. Это поможет выбрать архитектуру, которая будет масштабироваться вместе с вашей компанией. Возможно, уже на этом этапе имеет смысл обратиться к ИТ-партнеру за предпроектным обследованием и планированием внедрений. Такой подход позволит спланировать внедрение и сделать именно то, что нужно.
- Из имеющихся вариантов сделайте выбор в пользу решения со слабосвязанной архитектурой. Таким образом вы сократите затраты на развитие и поддержку.
- Разработайте план сохранения и передачи знаний и документации, чтобы снизить риски при смене команды и облегчить обучение новых специалистов.
- Внедрите систему непрерывного мониторинга производительности и затрат, чтобы своевременно находить проблемы и оптимизировать расходы.
- Регулярно пересматривайте стратегию TCO, учитывая изменения в технологиях и бизнес-требованиях.
Помните, что инвестиции в качественную архитектуру и грамотное планирование на ранних этапах помогут существенно снизить затраты на протяжении всего жизненного цикла системы и повысить ее эффективность.
В целом все верно, кроме некоторых вредных советов, например: "Внедрите систему непрерывного мониторинга..."
Поделитесь, почему этот совет вреден?
Все верно, но в текущих условиях быстро меняющегося рынка писать документацию с оптимальным time-to-market крайне сложно и дорого. То же самое касается и долгосрочных стратегий: сегодня картина одна, через месяц — уже все поменялось. Поэтому приоритет — быстрее выкатить продукт, быстрее допустить максимум ошибок и идти дальше. В таком подходе документация часто превращается в технический долг, который, скорее всего, никто и никогда не будет устранять. В определенный момент приходится делать выбор: инвестировать в гибкость и понятность для будущих участников или сфокусироваться на текущей команде и её ключевых специалистах.
100% согласен по большинству пунктов, кроме одного: бесполезность стратегии. Сами проповедуем (громкое слово, конечно) гибкость и способность к быстрым изменениям в ИТ именно потому, что сейчас разрабатывать на века - тупиковый путь.
Но плюс стратегии - в выравнивании у всех ЛПР и команды понимания, куда мы идем. Конкретные шаги и маршруты в обозримом будущем могут меняться. Но общее направление останется плюс-минус одним, и это поможет выбирать из бесконечного множества решений и отбрасывать очевидно неподходящие варианты