Компании по всему миру включаются в цифровую трансформацию - используют новые (или уже существующие) технологические возможности, чтобы более эффективно работать с клиентами, оторваться (или не отставать) от конкурентов и соединить различные аспекты своего бизнеса. Но чтобы добиться успеха или просто извлечь максимальную выгоду из используемых технологий, им необходимо избавиться от тяжелого бремени технического долга. Попросту говоря, технический долг возникает, когда вы выбираете неидеальные краткосрочные решения, которые позже потребуют существенных исправлений и доработок, его образуют несовместимые системы, дополнительное программное обеспечение, необходимое для их работы, и дополнительные усилия для выполнения всех этих действий.
Поскольку технический долг возникает, когда компания идет легким путем, выбирает быстрое решение, а не долгосрочные инвестиции, он влечет за собой множество проблем здесь и сейчас. Он доставляет неудобства каждый раз, когда людям нужно скоординировать работу разных отделов. Учитывайте еще постоянные издержки обмена данными между системами, не поддающиеся количественному определению издержки, связанные с замедлением работы из-за таких систем, будь то в процессе цифровой трансформации или в ситуации, когда вам важно действовать в ответ на действия конкурента, и в итоге ту цену, которую вам придется в какой-то момент заплатить за переделку и упрощение систем. Технический долг и его издержки со временем усугубляются.
Поначалу руководители могут не воспринимать технический долг всерьез и считать его ответственностью ИТ-отдела. Однако при таком подходе не учитываются реальные причины проблемы. В действительности причиной технического долга является структура бизнеса и собственные системы и язык, разрабатываемые различными отделами для выполнения своих задач.
Технический долг растет по мере того, как в каждом отделе начинают применять все более несовместимый язык ведения бизнеса и встраивают его в свои системы. Чтобы сократить долг, компании должны прежде всего создать компактный, хорошо продуманный общий язык и строго следовать ему.
Обманчивая динамика
Технический долг растет в три простых этапа. Во-первых, предпосылки для его возникновения закладываются по мере того, как бизнес растет, меняется и внедряет инновации, что естественным образом ведет к тому, что команды и отделы создают и применяют новый, все более специализированный язык бизнеса, помогающий им эффективно выполнять свою работу. Возможно, это не было проблемой, когда компания была маленькой или когда коммуникации между отделами происходили на уровне конкретных людей, но со временем языковой барьер растет, и это значительно затрудняет обмен данными между отделами. Вот как можно проиллюстрировать эту мысль. Задумайтесь, что "клиент" означает совершенно разные вещи для разных отделов: для отдела маркетинга это "потенциальный потребитель", для отдела продаж - "человек с правом подписи", для финансового отдела - "тот, кто отвечает за оплату счетов". Обратите внимание, что в контексте всей компании клиент имеет три различные роли, и каждый отдел сосредоточен только на одной.
Конечно, каждому отделу так проще выполнять свою работу. Однако со временем отделам становится все труднее работать вместе.
Во-вторых, чтобы автоматизировать свою работу, отделы пользуются базами данных, компьютерными системами и приложениями, в которых применяются модели и базы данных, отражающие и фиксирующие язык бизнеса их пользователей. В то время как автоматизация может помочь каждому отделу повысить эффективность, она также может означать, что в итоге в компании будет использоваться множество несовместимых баз данных на уровне отделов, и они будут не очень хорошо работать друг с другом. В частности, каждый отдел использует в своей базе данных собственное представление о "клиенте". Один из заметных результатов этой проблемы - руководство не может получить четкого ответа на вопрос "сколько у нас клиентов?"
В-третьих, люди тратят много усилий на то, чтобы несовместимые системы могли функционировать вместе: коммерческие отделы ищут обходные пути, отдел ИТ разрабатывает специализированные интерфейсы, чтобы объединить эти системы. Эти меры создают дополнительные сложности, но без них системы просто не будут работать.
Бремя этого технического долга - несовместимые системы, дополнительное ПО для обеспечения их работы и дополнительные усилия для выполнения всех этих действий - будет продолжать расти, пока компании не поставят преграду необузданному росту несовместимого языка.
Решение - в общем языке
Единственный доказанный способ решить эту проблему - предпринять меры еще на первом этапе, через общий язык. Задача может казаться непростой: в компаниях употребляют тысячи терминов. Но есть и хорошая новость: если сначала сосредоточиться на небольшой подгруппе терминов, соответствующих ключевым понятиям, единым для компании, то задача станет посильной. Как показывает наш опыт, для трансформации всей компании достаточно не более 150 таких понятий. Небольшой проект, такой как разработка клиентского приложения, может потребовать менее десятка терминов.
Вспомним выше приведенный пример, когда разные люди вкладывают в понятие "клиент" разный смысл. Секрет разрешения этого конфликта состоит в том, чтобы признать и прояснить лежащие в основе базовые идеи.
Во-первых, относитесь к "потенциальным потребителям", "лицам с правом подписи" и "ответственным за платежи" не как к объективным единицам, а как к ролям, которые исполняет один или несколько человек или группа людей (например, организация).
Обобщите понятие еще немного, определив "сторону" как "человека или организацию, представляющие интерес для нашего предприятия".
Воспользуйтесь гибкостью этого определения, приписав "стороне" столько ролей, сколько удобно для вашего бизнеса.
С помощью такого подхода с единой, общей базой данных может работать отдел маркетинга, продаж, финансов и любой другой, имеющий дело со "сторонами". Например, сторона, важная для отделов маркетинга и финансов, является и потенциальным потребителем, и лицом, ответственным за платежи. Такой подход позволяет отделам компании отказаться от собственных систем, минимизировать необходимость искать обходные пути и избавиться от потребности в специализированных интерфейсах, что сократит технический долг. Внутри отделов маркетинга, продаж и финансов команды не увидят разницы. Отделив стороны от их ролей, вы облегчите коммуникации при взаимодействии отделов.
Также обратите внимание, что в результате можно собирать гораздо более ценные данные, так как они описывают весь спектр отношений между сторонами и компанией. А с полноценными наборами данных появляются возможности для продвинутого анализа и дальнейшей цифровой трансформации.
Не стоит недооценивать требуемые усилия
Как рассказал мне Лен Силверстон, консультант из Universal Mindful и лидер, помогающий компаниям разрабатывать общий язык, "общий язык и модели данных обеспечивают архитектуру, определяющую направление дальнейшего технологического развития". Но разработка этих основополагающих понятий, достижение согласия по ним и их использование - непростая работа. Она требует четкого руководства и мощной коалиции людей с разнообразными навыками. В частности, важен топ-менеджер, обладающий властью, авторитетом и влиянием, способный указать на необходимость общего языка, предложить убедительное экономическое обоснование, задать направление, обеспечить ресурсы, привлечь других и заручиться их поддержкой.
Здесь важно подчеркнуть: люди, возглавляющие трансформацию, могут не избежать перечисленных выше ошибок и станут доказывать, что инвестиции в общий язык замедлят их работу. Возможно, но если этого не сделать, позже трансформация замедлится еще больше. Чтобы оценить ситуацию выбора, нужен лидер очень высокого уровня.
Для разработки необходимого общего языка этому лидеру также придется собрать разнообразную команду, которая будет выполнять эту работу, и управлять ею. Она должна включать в себя:
• Разработчиков концептуальной модели, способных обнаружить ключевые понятия, упомянутые выше.
• Квалифицированных, разбирающихся в бизнесе специалистов, умеющих изложить эти понятия ясным, точным языком.
• Специалистов в области ведения переговоров, которые могут уладить разногласия между различными группами.
• Инициаторов перемен, способных убедить других в необходимости использования общего языка.
• Архитекторов и технических специалистов, которые смогут применить общий язык в системах.
Пожалуй, образцом использования общего языка для сокращения технического долга может служить Aera Energy LLC, американская энергетическая компания, расположенная в Калифорнии. Aera образовалась в результате слияния и унаследовала сотни неинтегрированных устаревших систем и непоследовательных методов управления информацией. Покупка крупной компании через год после слияния усугубила проблему. Спустя несколько лет Aera внедрила ERP-систему, которая обеспечила некоторую интеграцию и новую функциональность. Но в компании по-прежнему применяли сотни доставшихся в наследство систем.
Руководство Aera признало, что ситуация становится все более неприемлемой и что для решения проблем им необходим общий язык. Чтобы отразить суть бизнеса, Aera понадобилось всего 53 ключевые концепции. Они легли в основу долгосрочных данных, приложения и архитектуры технологий, позволив Aera в течение нескольких лет заменить сотни систем и добавить новые возможности. (Уведомление: в этой работе участвовали Хэй, Йонке и Закман.)
Продуманный и грамотно внедренный общий язык является разумной инвестицией. 53 термина Aera послужили основой для трансформации системы обработки транзакций, создания полномасштабного хранилища данных предприятия, поддерживающего новую систему отчетности и аналитики и другие функции, введения новых месторождений нефти и газа, выполнения новых требований регулирующих органов, с их внедрением стало возможным менять бизнес-процессы и проводить реорганизацию - при этом не увеличивая технический долг.
При планировании цифровой трансформации в компании легко отвлечься на новые технологии. Но не забывайте, что ваша цель - максимально использовать имеющиеся у вас данные, а это невозможно, если все ваши данные не будут говорить на одном языке.
Об авторах
Джон Закман (John A. Zachman) - создатель модели архитектуры предприятия, онтологии предприятия (The Framework for Enterprise Architecture: The Enterprise Ontology).
Дэвид Хэй (David C. Hay) более 35 лет занимается созданием концептуальных моделей данных (онтологий) в поддержку стратегического планирования и планирования потребностей, работал в различных отраслях и государственных учреждениях.
Лванга Йонке (C. Lwanga Yonke) возглавляет направление качества информации и управления данными в Aera Energy.
Томас Редман (Thomas C. Redman) - эксперт по данным, президент компании Data Quality Solutions. Редман консультирует стартапы, международные компании, руководителей на всех уровнях по вопросам работы с данными. Он обращает особое внимание на качество, аналитику и организацию процессов.