версия этой статьи, переведенная Есикой Дандерфер Что, если бы вы не знали, сколько у вас долгов? Было бы неудобно оказаться в таком положении, если бы вы не знали, сколько это стоит и в какой степени это мешает вашей компании вносить операционные улучшения, реагировать на изменения рынка или даже полностью трансформировать бизнес.
Более того, что, если почти любой в вашей организации может взять долг без разрешения? Например, ваш руководитель отдела недвижимости может быстро заключить договор аренды на несколько лет с низкой арендной платой в первый год, но со значительным ростом арендной платы в последующие годы, и никто не расскажет об этом, кроме как в разговоре.
Все это звучит как неосмотрительное управление, но на самом деле это довольно распространено в бизнесе. Загвоздка в том, что этот вид «долга» не принимает форму традиционных финансовых инструментов, которые мы все так хорошо знаем.
Технический долг обладает всеми этими характеристиками.
Долг в своей простейшей форме — это заимствование сегодня с намерением и обещанием погасить в будущем. Долг имеет смысл, когда сегодняшние займы приведут к лучшему завтра, например, займы для колледжа или покупка дома. Долг, как правило, плох, когда взятие взаймы сегодня приведет к еще худшему завтра, например, вы идете на дорогой ужин и кладете его на кредитную карту, которую вы не сразу погасите.
С корпоративной точки зрения долг может быть хорошим, когда он берется для финансирования инвестиций, которые обеспечат больший доход, чем стоимость долга. Это также может иметь смысл, если вы планируете продать бизнес задолго до погашения долга. Недостатком долга является то, что он сопряжен с очень реальными расходами, которые тянут наличные деньги и прибыль, ограничивают гибкость и могут стать настолько обременительными, что в конечном итоге могут привести к банкротству.
До сих пор метафора, на которую мы ссылаемся, касается финансового долга, но еще одна форма долга — технический долг (или «технический долг») — имеет много схожих характеристик и должна измеряться, управляться и вступать в нее преднамеренно. . Если это позволяет вашей компании выйти на рынок впереди конкурентов, скорее всего, оно того стоит. Аналогичным образом, взятие технического долга для устранения потенциально серьезной уязвимости безопасности тоже, вероятно, того стоит.
Однако у технического долга есть и обратная сторона, приводящая к неэффективности и инертности, например, когда один отдел не хочет использовать программное обеспечение другого или если вы несколько раз откладываете обновление, чтобы достичь краткосрочных финансовых целей.
Технический долг — это термин, который использовался в основном в техническом сообществе с тех пор, как Уорд Каннингем, программист, придумал эту фразу в 1992 году. Его использование началось недавно и заняло центральное место с распространением гибкого программирования. Технический долг, обсуждаемый в этой статье, связан не с методологией программирования, а скорее со стратегическими последствиями его существования.
Проще говоря, технический долг — это дополнительные затраты и потеря гибкости для вашей компании в результате предыдущих решений, которые были приняты для экономии времени или денег при внедрении новых систем или обслуживании существующих. Это происходит, когда системы неправильно интегрированы или код слишком сложен. Это связано с рядом причин, таких как неэффективность, время выхода на рынок или использование устаревших версий программного обеспечения, среди многих других.
Вот некоторые наглядные примеры:
На приведенной ниже диаграмме показано, как технический долг отличается от других технологических реализаций, которые могут быть реализованы в технологическом стеке компании. Часто ошибочно принимаемый за ошибку, технический долг сильно отличается тем, что его присутствие может быть неочевидным. В этом и заключается опасность, так как чем дольше он остается нетронутым, тем выше будет величина эффекта в будущем.
Как финансовый директор, который работал в сфере ИТ и отчитывался передо мной по ИТ в компаниях с высокой долей заемных средств, меня поразило, насколько технический долг похож на традиционный долг. Меня также поразило, насколько это непрозрачно и рискованно. Те, кто имеет финансовое образование, хорошо разбираются в механизмах финансового долга — он осязаем и его легко рассчитать. Но это не относится к техническому долгу, который часто неправильно понимают или ошибочно принимают за чью-то проблему.
Короткий ответ заключается в том, что денежные затраты вполне реальны. Есть также некоторые важные косвенные затраты, которые следует идентифицировать, а также отдельно измерять и управлять ими. Ниже я подробно расскажу о некоторых примерах этих расходов:
Технический долг так же реален, как и процентные платежи. Однако обычно это проявляется в отчете о прибылях и убытках более косвенным образом, чем простой расход по строке «проценты», например, следующим образом:
Численность персонала
Накладные расходы
Продажи
Оборотный капитал
В то время как с реальными затратами связаны фактические суммы в долларах, существуют также мягкие затраты, которые, несмотря на то, что их труднее измерить и реализовать экономию, оказывают абсолютное влияние на результаты вашего бизнеса. К ним относятся:
Рыночная аналитика
Производительность
Глядя на сравнение технического и финансового долга, одно из ключевых различий заключается в том, что первый не имеет формального контроля. Что касается финансового долга, обычно существуют кредитные комитеты, группы по управлению активами и пассивами, а также сотрудники казначейства, которые следят за уровнями, как ястреб. Однако из-за технического долга в традиционном бизнесе существует очень мало таких средств контроля.
При традиционном долге правление вместе с генеральным директором и финансовым директором обычно устанавливает структуру капитала, то есть размер собственного капитала, размер долга и тип долга (револьверный, основанный на активах или ванильный необеспеченный). В таблице предельных значений даже указано, какой долг будет погашен и когда. После того, как все формально решено, запускается структурированный процесс привлечения долга.
Кредиторы смотрят на способность организации погасить долг посредством оценки истории погашения долга, кредитных рейтингов и качества обеспечения, поддерживающего его. Тем не менее, ничего из этого формального процесса, количественной оценки и утверждения не происходит, когда возникает технический долг. Давайте посмотрим, как и почему это происходит через процессы, в которых возникает технический долг:
Время выхода на рынок решает все в бизнесе. Внедрение новой технологии происходит намного быстрее, когда это можно сделать отдельно. К сожалению, последствия этого заключаются в том, что другие системы не синхронизируются с реализацией. Для бережливых организаций с простым набором технологий это может показаться не таким уж плохим.
Однако это становится проблематичным по мере увеличения сложности системных конфигураций. В конце концов, технологии автоматизируют процессы и собирают данные, которые преобразуются в информацию. Технологии, которые не интегрированы, приводят к тому, что бизнес-процессы не работают вместе, и возникают разные версии правды.
Когда время приносится в жертву скорости, установленные протоколы тестирования могут быть проигнорированы или от них можно отказаться. Обычно это приводит к «ошибкам» в будущем, которые проявляются в некоторой форме деградации системы и отвлечении времени разработчиков на их исправление.
Если мы посмотрим на влияние технологического долга с течением времени, то чем дольше проблема остается нетронутой, тем выше величина эффекта. То, что начинается как небольшое упражнение по рефакторингу кода, может снежным комом превратиться в целую работу по модернизации и замене.
Посмотрим правде в глаза:исполнительные команды находятся под постоянным давлением, чтобы достичь цифр. Откладывание трат сегодня может помочь вам заработать квартал, но, как и в случае с займом, вы должны вернуть его в какой-то момент. Вот несколько способов, с помощью которых компании могут сэкономить деньги в краткосрочной перспективе, но в результате получить технический долг:
Иногда стоимость и проблемы с внедрением периодического обновления программного обеспечения могут привести к его задержке. Иногда это продолжается годами. Мы все виновны в принудительном закрытии Microsoft AutoUpdate, когда оно появляется в неудобное время.
Когда системы в конечном итоге сильно отстают от своей текущей версии, новое программное обеспечение, которое должно интегрироваться с ним, просто не может. Более того, обновление сразу нескольких версий обычно обходится дороже и почти всегда занимает больше времени, чем поддержание актуальности.
По мере усложнения организаций простое усилие по синхронизации циклов обновления оборудования может стать непосильным и дорогостоящим. Это может привести к тому, что текущее оборудование будет чрезмерно загружено, а между командами возникнут большие различия в качестве оборудования. Некоторые команды разочаровываются, покупают новое оборудование и просто тратят его на свой рабочий бюджет вместо того, чтобы ждать, пока ИТ-отдел инициирует обновление.
Это несоответствие влияет на производительность и совместимость оборудования/файлов для совместных упражнений.
Вместо того, чтобы просто говорить о проблемах, давайте проявим инициативу и предложим некоторые решения для устранения технического долга.
Для этого мы можем обратиться к методам, используемым для управления финансовым долгом. Чтобы управлять своими обязательствами, вам сначала нужно знать, каковы они, сколько они стоят и условия их оплаты. Теперь давайте разберемся с техническим долгом.
Финансовый долг состоит из траншей, которые определяются старшинством каждого предмета (например, старшего, мезонина или револьвера), что, в свою очередь, показывает, что будет погашено первым. Технический долг имеет аналогичную структуру старшинства; для начала вы должны начать с ваших критически важных систем. Какой у них технический долг? Затем посмотрите на более широкую экосистему — точнее, какой технический долг между ваши системы вызывают расходы?
Не усложняйте этот процесс. В какой-то момент вы захотите перейти к оценке сверху вниз, но вам не обязательно начинать с этого. Попросите вашего ИТ-руководителя объединить вашу управленческую команду, выполнив это домашнее задание:
<цитата>Если бы мы полностью погасили весь наш технический долг год назад, как мог бы сложиться этот (или предстоящий) год лучше?
Получите десять лучших идей и поместите их в матрицу 2x2:легко/трудно окупить по одной оси и степени выгоды по другой. Надеюсь, визуальный ряд поможет вам понять, с чего начать.
Матрица мозгового штурма по разрешению технических долгов| Преимущества урегулирования ► | Сильный | ||
|---|---|---|---|
| Слабо | |||
| Сложно | Легко | ||
| ▲ Усилия по выплате долга | |||
Оттуда углубитесь, чтобы подтвердить свои предположения о размере приза и усилиях. Нейтральность здесь играет ключевую роль, поэтому будьте осторожны с поставщиками программного обеспечения, которые предлагают провести «бесплатную оценку».
Как только вы узнаете, какой у вас технический долг, вам нужно решить, как с ним справиться. Вариантов много.
В конечном итоге может быть лучше ничего не делать. Для долга, который оценивается как «небольшой» или с «низкой процентной ставкой», может быть оптимальным просто оставить его — аналогично, если существует значительный «штраф за досрочное погашение» за досрочное погашение. Могут быть и стратегические преимущества. Отставать на одну версию и оставаться там, как правило, нормально, а иногда это дает преимущество в том, что позволяет решать проблемы за чужие деньги.
Выплата или сокращение технического долга потребует замены систем и снижения затрат. Это можно сделать либо сразу, либо через какое-то время в процессе постепенных улучшений. Как и в случае с финансовым долгом, существуют творческие способы «рефинансирования» технического долга, одним из которых является аутсорсинг обслуживания. В конечном итоге это может стоить дороже, но может быть распределено, чтобы снизить непосредственные затраты, и с помощью принципов разделения труда делегировать задачу более специализированной организации.
Появление облачных программных и аппаратных услуг также приводит к сравнению с популярностью финансирования на основе аренды. Использование облачных сервисов также является эффективным инструментом сокращения технического долга, как за счет устранения требований капитальных затрат, так и за счет переноса акцента разработки на поставщика облачных услуг.
Не пугайтесь стоимости сокращения технического долга и не пытайтесь погасить его сразу. Это было бы амбициозным предприятием, которое могло бы сокрушить организацию любого размера или баланса.
Опять же, возвращаясь к финансовым сравнениям, имейте в виду, что сначала нужно погасить кредитную карту с самой высокой процентной ставкой. Это просто означает, что в первую очередь нужно атаковать высокоценные и малозатратные действия.
В предыдущем разделе я обсуждал различные способы решения технического долга. При оценке стоимости каждого из них лучше провести сравнение. Ранжирование стоимости денежных потоков для каждого потенциального результата может позволить заинтересованным сторонам получить четкое представление о компромиссах и преимуществах каждого пути. Пример такого визуального элемента приведен ниже.
Это сравнение показывает компромисс, существующий между теоретическим решением и резким контрастом между решением проблемы и бездействием («существующая базовая линия»). В этом примере переход на облачное решение на основе SaaS будет наиболее экономичным вариантом для бизнеса.
После того, как вы установили свой базовый уровень и план атаки, вы захотите сохранить эту видимость и предотвратить появление новых долгов. Думайте об этом упражнении как о новом старте и возможности внедрить лучшие практики для предотвращения проблем. эскалация в будущем.
У большинства технологических проектов есть формальный процесс утверждения, включающий исполнительного спонсора, цель высокого уровня, ожидаемые выгоды, график и, конечно же, затраты. Это отличное место, чтобы избавиться от нового технического долга, который возникнет, и его обоснования.
Не переусердствуйте с установлением новых стандартов. Точно так же, как вы выпускаете корпоративные кредитные карты с заданными лимитами, вы не хотите чрезмерно управлять техническим долгом. Большая часть технического долга невелика и связана с написанием кода, который быстро окупится. Особенно это касается гибкой разработки. Доверьте установку и контроль этого порога своему руководителю ИТ-отдела.
В крупных компаниях в ИТ есть процесс, который называется «управление изменениями». Прежде чем новое программное обеспечение будет запущено, оно обычно проходит через управление изменениями. Проще говоря, задача управления изменениями заключается в обеспечении того, чтобы новые изменения в технологической системе компании не влияли на другие системы. Они делают это, следя за тем, чтобы новая система соответствовала стандартизированным методам и процедурам. Рассмотрите возможность использования этого процесса для предотвращения или, по крайней мере, выявления новых долгов.
Технический долг — это реальная стоимость ведения бизнеса, реальная причина сбоев в работе систем и снижение гибкости компании в целом. Тем не менее, это не должно быть постоянным бременем, и умные финансовые директора будут знать, сколько технического долга у их организации и что нужно для его оптимизации.