Инструменты методики АЦТ, часть 40: облачные вычисления (Cloud Computing), CRM-системы (Customer Relationship Management), системы управления мастер-данными (MDM) и блокчейн (Blockchain)

Это сороковая статья цикла по инструментам методики «Аккордная цифровая трансформация». Продолжаем подгруппу G3 «Инфраструктура и данные» — инструменты G3-01, G3-02, G3-03 и G3-04.

Четыре инструмента этой статьи составляют инфраструктурный слой группы G. Облачные вычисления (G3-01) предоставляют вычислительные мощности по модели аренды вместо владения оборудованием. CRM-системы (G3-02) хранят и обрабатывают данные о клиентах как категория программного обеспечения. Системы управления мастер-данными (G3-03) удерживают единые эталонные справочники для всех систем предприятия. Блокчейн (G3-04) обеспечивает доверие между независимыми участниками через распределенный неизменяемый реестр. Трудоемкость составляет 28 часов у облачных вычислений, 30 у CRM-систем, 36 у управления мастер-данными и 40 у блокчейна. В сумме 134 часа.

Отдельное замечание по составу статьи. Управление взаимоотношениями с клиентами как деловая стратегия и история дисциплины подробно разобраны в двадцать восьмой статье цикла (инструмент D2-05). Здесь CRM рассматривается иначе — как категория корпоративного программного обеспечения в одном ряду с облаком, мастер-данными и блокчейном, то есть с точки зрения инфраструктурного выбора, а не бизнес-практики.

G3-01 — Облачные вычисления (Cloud Computing)

Откуда появился инструмент. Идею вычислений как коммунальной услуги, доступной по мере надобности подобно электричеству, высказал в 1961 году информатик Джон Маккарти. Практическое воплощение потребовало десятилетий: в 1990-е годы распространилась модель поставщиков прикладных сервисов, предлагавших доступ к программам через интернет вместо их установки на компьютер заказчика. Переломным стал 1999 год, когда компания Salesforce первой в истории предложила полноценное корпоративное приложение целиком через браузер, без установки на стороне клиента; примечательно, что этим первым приложением была именно система управления взаимоотношениями с клиентами. Настоящую инфраструктуру вычислений по требованию создала компания Amazon: в 2006 году она открыла сторонним пользователям сервисы Simple Storage Service и Elastic Compute Cloud, выросшие из простаивающих мощностей ее собственных дата-центров.

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

Значение перехода от владения к аренде вычислительных мощностей видно на масштабном переносе корпоративных приложений в облако.

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

Границы применимости. Инструмент применим там, где нагрузка на вычислительные ресурсы меняется во времени, а капитальные вложения в собственное оборудование трудно окупить при таком колебании: в разработке программного обеспечения, аналитике, сезонных нагрузках на инфраструктуру. По методике это инструмент средней сложности, наименее трудоемкий в статье. Первое ограничение касается соответствия требованиям законодательства о персональных данных и иным нормативным требованиям, что для российских предприятий означает выбор между российскими облачными провайдерами и оценку соответствия конкретного облака требованиям регуляторов. Второе — не всякое приложение выигрывает от переноса: устаревшие системы с жесткой привязкой к специфическому оборудованию переносятся дорого и с ограниченным эффектом. Третье — зависимость от поставщика: перенос инфраструктуры к одному облачному провайдеру создает зависимость от него, и переход к другому провайдеру впоследствии требует отдельных вложений. Облачные вычисления служат технической основой для CRM-систем (G3-02), управления мастер-данными (G3-03) и большинства инструментов группы G, требующих вычислительных мощностей.

Чек-лист перед переходом на облачные вычисления:

• Составлен перечень приложений — кандидатов на перенос, с оценкой пригодности каждого к облачной архитектуре.
• Проверено соответствие выбранного облачного провайдера требованиям законодательства о персональных данных.
• Рассчитана текущая стоимость владения инфраструктурой для сравнения с облачной моделью.
• Определена стратегия переноса для каждого приложения: перенос без изменений, переработка под облако или отказ от переноса.
• Оценена степень зависимости от конкретного облачного провайдера и стоимость возможного перехода к другому.
• Установлен порядок контроля фактических расходов на облачные ресурсы после перехода.

Типовые ошибки:

• Перенос без отбора. Всю инфраструктуру переносят в облако без оценки пригодности отдельных приложений. → Оценивать каждое приложение отдельно перед переносом.
• Игнорирование требований регуляторов. Данные размещают в облаке без проверки соответствия требованиям законодательства. → Проверять соответствие провайдера нормативным требованиям до переноса.
• Недооценка зависимости от провайдера. Инфраструктуру строят на решениях одного поставщика без оценки последствий. → Оценивать стоимость возможного перехода к другому провайдеру заранее.
• Отсутствие контроля расходов. Облачные ресурсы используются без отслеживания фактических затрат. → Устанавливать регулярный контроль расходов на облачную инфраструктуру.

G3-02 — CRM-системы (Customer Relationship Management)

Откуда появился инструмент. История CRM как деловой практики и стратегии работы с клиентами разобрана в двадцать восьмой статье цикла. Здесь стоит отметить один факт, связывающий этот инструмент с облачными вычислениями: первым коммерческим приложением, целиком доставленным через браузер без установки на компьютер заказчика, в 1999 году стала именно система управления взаимоотношениями с клиентами компании Salesforce. С тех пор CRM как категория программного обеспечения прошла путь от установки на собственных серверах предприятия к преимущественно облачной поставке, а в последние годы в России этот путь пополнился отдельным направлением — переходом с зарубежных платформ на отечественные решения.

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

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

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

Границы применимости. Инструмент применим на любом предприятии, ведущем систематическую работу с клиентами, при выборе между локальным размещением и облачной поставкой, между зарубежной и отечественной платформой. По методике это сложный инструмент. Первое ограничение относится к переносу данных: миграция с одной платформы на другую требует сохранения истории обращений и сделок, накопленной за годы, и потеря этой истории обходится предприятию дороже стоимости самого перехода. Второе — совместимость с прочими системами предприятия: CRM редко работает изолированно и требует интеграции с учетной системой, складом, производством. Третье — вопрос импортозамещения для российских предприятий: уход зарубежных платформ с рынка вынуждает планировать переход на отечественные решения заранее, а не в момент прекращения поддержки. CRM-система как категория инфраструктуры опирается на облачные вычисления (G3-01) как на способ поставки и связана с управлением мастер-данными (G3-03) в части данных о клиентах.

Чек-лист перед выбором или сменой CRM-системы:

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

Типовые ошибки:

• Перенос без плана сохранения данных. Систему меняют, не подготовив перенос накопленной истории. → Планировать миграцию данных как отдельный этап проекта.
• Игнорирование совместимости. Систему выбирают без учета интеграции с остальными системами предприятия. → Проверять совместимость до выбора платформы.
• Промедление с переходом на отечественное решение. Переход планируют только после прекращения поддержки зарубежной платформы. → Готовить план перехода заранее, не дожидаясь принудительного отказа.
• Смена системы без подготовки пользователей. Платформу меняют, обучение сотрудников не проводится. → Предусматривать обучение и сопровождение на период перехода.

G3-03 — Системы управления мастер-данными (Master Data Management, MDM)

Откуда появился инструмент. Дисциплина сложилась в 1990-е годы как ответ на разрастание разрозненных сведений об одних и тех же объектах — клиентах, поставщиках, товарах — в разных системах предприятия. Единого автора у метода нет; известность и распространение практика получила в начале 2000-х годов, когда ряд новых нормативных требований, включая закон Сарбейнса-Оксли 2002 года в США, заставил предприятия обеспечивать точность и прослеживаемость ключевых данных для финансовой отчетности. В России сходная практика существовала задолго до появления самого термина под названием нормативно-справочной информации — эта традиция восходит к системам планирования советского периода и в переработанном виде вошла в современные системы управления мастер-данными.

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

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

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

Границы применимости. Инструмент применим на предприятиях, где одни и те же объекты — клиенты, поставщики, товары — фигурируют в нескольких информационных системах одновременно: в холдингах с несколькими юридическими лицами, при слияниях и поглощениях, в компаниях с широкой продуктовой линейкой. По методике это сложный инструмент. Первое ограничение носит организационный характер: наведение порядка в данных требует согласия всех подразделений, ведущих эти данные по-своему, и без такого согласия проект блокируется на уровне процедур, а не самой технологии. Второе — постепенность: полный охват предприятия редко достижим сразу, и проект обычно ведется поэтапно, начиная с наиболее проблемных категорий данных. Третье — поддержание в дальнейшем: система мастер-данных требует постоянного контроля, поскольку без него разрозненность начинает накапливаться заново. Управление мастер-данными служит связующим звеном между CRM-системами (G3-02), учетными системами и прочими источниками данных предприятия.

Чек-лист перед внедрением управления мастер-данными:

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

Типовые ошибки:

• Попытка охватить все сразу. Проект запускают без поэтапного плана, пытаясь навести порядок во всех данных одновременно. → Начинать с наиболее проблемных категорий данных.
• Внедрение без согласия подразделений. Единый процесс вводят технически, подразделения продолжают вести данные по-старому. → Обеспечивать согласие подразделений до начала проекта.
• Отсутствие сопровождения после внедрения. Проект завершается, ответственность за поддержание качества данных не закреплена. → Назначать постоянную ответственность за качество данных.
• Разовый аудит без повторения. Данные приводят в порядок однажды и не проверяют повторно. → Устанавливать регулярный контроль состояния данных.

G3-04 — Блокчейн (Blockchain)

Откуда появился инструмент. Технология распределенного реестра впервые была описана в 2008 году как основа расчетной системы, не требующей посредника, и легла в основу криптовалютных сетей. Применение технологии к иным бизнес-задачам началось с расширения самого понятия блокчейна: в 2013 году программист Виталик Бутерин предложил концепцию платформы, поддерживающей смарт-контракты — программный код, автоматически исполняющийся при выполнении заданных условий, без участия посредника. Запущенная в 2015 году платформа Ethereum позволила использовать блокчейн не только для передачи ценности между сторонами, но и для автоматизации произвольных деловых процессов между независимыми участниками, что и открыло дорогу применению технологии за пределами криптовалют.

Суть и механика. Блокчейн используется для оптимизации процессов, укрепления доверия между участниками и снижения издержек. Изначально разработанная для обеспечения безопасности транзакций в криптовалютных сетях, технология теперь применяется в различных сферах, где важны прозрачность, безопасность и эффективность данных. Особенности технологии: децентрализация — нет единого центра управления, информация распределена на множестве узлов; прозрачность — все транзакции видны всем участникам сети, каждый может проверить подлинность и корректность данных; безопасность — благодаря криптографическим методам данные защищены от подделки и несанкционированного доступа.

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

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

Границы применимости. Инструмент применим там, где несколько независимых сторон должны доверять общим данным без единого центра управления: в цепочках поставок с множеством участников, в межбанковских расчетах, в системах прослеживаемости происхождения товаров. По методике это сложный инструмент, самый трудоемкий в статье. Первое ограничение связано с участием всех сторон: ценность блокчейна возникает только при подключении значимой доли участников цепочки, а частичное подключение оставляет прежние разрывы данных. Второе — нейтральность управления платформой: если один из участников контролирует инфраструктуру, конкуренты воспринимают это как риск, даже если техническая архитектура децентрализована. Третье — соразмерность задачи: там, где достаточно централизованной системы с назначенным оператором, распределенный реестр добавляет сложность без соразмерной выгоды. Блокчейн опирается на облачные вычисления (G3-01) как на инфраструктурную основу и связан с интеграцией стратегии ESG (E4-02) и блокчейном для отслеживания ESG-метрик (E4-01) как со смежными применениями технологии.

Чек-лист перед внедрением блокчейна:

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

Типовые ошибки:

• Технология без критической массы участников. Платформу запускают, рассчитывая на постепенное подключение остальных. → Оценивать готовность ключевых участников до запуска проекта.
• Управление платформой одним из конкурентов. Инфраструктуру контролирует одна из сторон отраслевой цепочки. → Обеспечивать нейтральное управление платформой или независимого оператора.
• Усложнение решения. Блокчейн применяют там, где задачу решает централизованная система. → Сопоставлять распределенное и централизованное решения по затратам.
• Оценка только по техническим показателям. Успех проекта измеряют скоростью и надежностью технологии, не отслеживая фактическое отраслевое признание. → Отслеживать долю подключенных участников как отдельный показатель успеха.

Резюме

Четыре инструмента этой статьи составляют инфраструктурный слой группы G, и объединяет их общая логика выбора: приобретение готовой инфраструктуры на определенных условиях, а не разработка собственного решения. Облачные вычисления заменяют владение оборудованием арендой мощностей. CRM-системы предоставляют готовую платформу для работы с клиентами вместо собственной разработки. Управление мастер-данными наводит порядок в уже существующих, но разрозненных сведениях. Блокчейн заменяет доверие к посреднику доверием к распределенной технической архитектуре. История TradeLens показывает предел этой логики: техническое решение способно обеспечить прозрачность и снизить издержки, но не способно само по себе создать отраслевое доверие там, где структура собственности платформы вызывает у участников подозрение. Суммарная трудоемкость в 134 часа ниже, чем в предыдущей статье о ядре искусственного интеллекта, и это отражает характер задачи: инфраструктурные решения требуют выбора и интеграции готовых платформ, а не построения новых моделей с нуля. Для промышленного предприятия отсюда следует практический вывод: выбор инфраструктуры определяется не только техническими характеристиками решения, но и тем, кто и на каких условиях им управляет, — а этот вопрос техническая архитектура сама по себе не решает.

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