Темой очередной беседы за круглым столом стала проблема обеспечения целостности информационных ресурсов. С ней приходится сталкиваться все чаще в условиях сложной и разнообразной автоматизации различных бизнес-процессов, при появлении новых концепций информационной поддержки бизнеса и методов работы с информацией.
Участники круглого стола:
Александр Сергиенко
генеральный директор интернет-компании «Аист»
Анна Бабкина
руководитель отдела корпоративной отчетности в «Объединенной металлургической компании»
Алексей Плотников
ИТ-директор компании «Русэнергосбыт»
Михаил Заборов
руководитель направления компании CUSTIS
Евгений Колесников
директор ЦДПО МФТИ
Ведущий – Сергей Костяков
главный редактор Intelligent Enterprise
Intelligent Enterprise: Каковы предпосылки самого возникновения рассматриваемой нами проблемы? Что, по вашему мнению, способствует тому, чтобы на целостность и непротиворечивость данных наконец обратили внимание?
Михаил Заборов: Начну с рассуждения по принципу «от противного». Часто нет ничего страшного в том, что данные не являются в полной мере целостными. Возьмем для примера потоки данных об остатках товаров в торговой сети. Их два, и они связаны с решением разных задач. Это, с одной стороны, управленческий учет — и тут всегда необходимо знать, какие активы есть у компании. В таком случае целостность данных, собираемых из разных систем, важна. При этом актуальность (то есть гарантированная точность этих данных на любой момент времени) не слишком значима. Покупателям же необходима информация другого плана. В частности, о наличии конкретного товара в определенных магазинах сети в данный момент. Эта задача решается совсем другим способом. И эти два потока данных никому не придет в голову сравнивать. Тут ключевым вопросом является то, для каких задач используется информационный ресурс: для централизованного учета или для повышения качества обслуживания покупателей.
Или другой пример. Можно поставить задачу перед информационной системой так, чтобы фиксировать, сколько учеников посещало занятия на определенную дату. Но если необходимо следить за этим в режиме онлайн, то это будет уже совсем другая задача. И обе эти задачи необходимо решать с опорой на информационные ресурсы с разными качественными характеристиками.
Сергей Костяков: Не вполне соглашусь. Возьмем для примера ту же розничную торговлю. Мы пробиваем по кассе чек. И при кассовых операциях фиксируется масса полезной информации, которая позволяет планировать продажи, сокращать издержки за счет выявления неочевидных закономерностей; мало того, эта информация может оказаться весьма полезной даже для производителя проданной в данный момент продукции. Хотя совершенно понятно, что чек пробивается вовсе не для этих целей.
Михаил Заборов: Очень лукавый пример. Пробивание чека на кассе порождает довольно много событий. И от того, как мы смотрим на это, требуется, во-первых, разная аналитика, а во-вторых, разная точность. Когда надо отслеживать поступление денег, то, скажем, и возврат товара, и, прошу прощения, его хищение тоже интересны в качестве первичной информации. Но когда стоит задача провести анализ оборота по поставщикам, то на основе тех же данных о продажах решаются совсем другие задачи. Иными словами, при учете продаж важно, чтобы ни одна единица товара не пропала в неизвестном направлении. Когда же необходимо определить влияние маркетинговой акции на продажи, то вопросы к системе и требования к самой информации уже совсем другие.
Александр Сергиенко: Сказанное Михаилом — это наглядный пример того, насколько важна точка зрения владельца бизнес-процесса, с позиции которого, как правило, должна создаваться процессная модель. А уже за нею создаются логическая модель, модель данных и так далее. В подтверждение своих слов напомню, что, скажем, при функциональном моделировании (стандарт IDEF 0) определяющим является то, чья точка зрения закладывается в конкретную модель. Ведь генеральному директору нужен один набор данных, маркетологу совсем другой, ИT-директору — третий, покупателю — четвертый и т. д.
Заказчик и интегратор зачастую сталкиваются с противоречиями, которые заключаются в том, что компания вследствие недостатка средств вынуждена идти на лоскутную автоматизацию, хотя рядом может существовать классический, хорошо описанный бизнес-процесс. Иногда в условиях реального бизнеса это единственно возможный вариант. Если компания в таком виде продолжает развиваться и расти, она вполне может выйти на некий новый уровень финансовых возможностей и позволить себе более дорогое комплексное решение. Беда только в том, что рост финансовых возможностей совсем не обязательно совпадает с ростом уровня зрелости предприятия. Покупка систем автоматизации без учета уровня зрелости организационной среды компании, ее процессного управления ведет к тому, что внедрение решения, пусть и хорошо себя зарекомендовавшего, скорее всего будет неудачным. Пожалуй, это можно считать и источником проблем при оценке непротиворечивости данных, существующих ИT-ресурсов компании.
Михаил Заборов: Компании, внедрившие даже наиболее мощные системы автоматизации бизнес-процессов, все равно решают те же задачи бизнес-аналитики, что и компании, которые по тем или иным причинам этого не сделали. Иными словами, весь цикл обработки информации приходится проводить заново и смотреть на весь арсенал данных, которым обладает предприятие, тоже во многом по-новому. При этом наличие нескольких систем, на основе данных которых строится эта бизнес-аналитика, может как облегчать, так и затруднять этот процесс.
Александр Сергиенко: Надо сказать, что большая часть компаний не может позволить себе держать собственных бизнес-архитекторов. А когда их нет, то превалирует решение «от руководителя», который говорит «надо», после чего ИT-управленец (CIO) покупает систему и внедряет ее. В итоге не совсем системного, структурированного подхода, как правило, образуется «винегрет» из данных и отчетов. Устаревшие ИT-решения корректно, методически обоснованно из эксплуатации не выводятся. Они продолжают жить, а вместе с этим в системе полноправно живут данные, которые продолжают генерироваться. Такие серьезные методологические ошибки являются одним из источников всяческого рода расхождений, нарушения целостности формирования управленческих решений.
Алексей Плотников: Сложность эксплуатации информационных систем напрямую зависит от объема хранимых и обрабатываемых неструктурированных данных. Так что служба ИТ является ярым противником подхода, связанного с неконтролируемым их накоплением. Коллеги весьма точно обрисовали ситуацию. Любое предприятие направлено на определенную, как правило, весьма ограниченную сферу деятельности. Ею ограничен и масштаб беспорядка с данными.
Если в качестве примера взять нашу компанию, то дополнительные информационные источники для нас являются базисом для дальнейшего развития бизнеса. Огромный поток информации, связанной с функционированием рынка электроэнергетики, требует тщательного анализа. Пример — задача прогнозирования потребления электроэнергии. На точность прогноза влияют как более очевидные факторы, такие как статистика потребления за прошлые периоды, прогноз погоды, сменные графики работы и пр., так и ряд факторов, выявляемых только после тщательного анализа большого объема сопутствующей, зачастую неструктурированной информации. Задача ИТ-службы в данном случае — создание гибкого ИТ-ландшафта, позволяющего без глобальных изменений собирать, хранить и передавать в обработку данные из различных источников нашим бизнес-аналитикам.
И тут нужны не лоскутные, а целостные решения. Причем использование решений от одного вендора не дает гарантии целостности. Соглашусь с Александром, что успешность внедрения целостного решения зависит от зрелости самой компании. При внедрении той же SAP часто приходится наблюдать классические примеры лоскутной автоматизации, где разные модули если и связаны, то очень слабо.
Одно из требований к обрабатываемой информации — ее непротиворечивость. Но часто бывает так, что информация поступает из нескольких источников, причём проходя некую предварительную обработку. В итоге возникает задача — определить, какую информацию считать истинной, а какую нет. Вот отсюда и вытекает задача аналитических систем: организация потоков информации.
Анна Бабкина: В нашей компании сейчас стоит задача поддержки целостности данных при интеграции различных систем (MES, ERP, системы планирования) — когда данные, появившиеся в одной системе, должны быть переданы в другую для последующей обработки и использования в связанных бизнес-процессах, которые поддерживаются в различных ИТ-системах. А также стоит вопрос при выборе системы-источника для загрузки корпоративного хранилища, учитывая, что одна и та же информация фигурирует в нескольких системах, и она же используется при формировании отчета для менеджеров. Компания должна представить непротиворечивую картину ситуации.
Intelligent Enterprise: Хотелось бы прояснить понятие архитекторов, о роли которых говорят очень часто, кода речь заходит о качестве информационного ресурса…
Александр Сергиенко: Приведу в пример отрасль телекома. В начале 90-х годов ряд крупных операторов на Западе объединились в некоммерческую ассоциацию TeleManagement Forum — TMF, ставшую в свою очередь источником концепции «эффективного оператора» (сокращенно NGOSS — next generation operations software and systems). В основе этой концепции лежат три краеугольных камня: архитектура процессов, архитектура взаимодействия и архитектура данных. Её внедрение позволяет оператору управлять своим развитием на основе виртуализированной модели предприятия, реализованной в программном продукте Casewise. Это мощный инструмент не только бизнес-моделирования, но и структурирования базы знаний компании по основным бизнес-процессам. В таком случае при необходимости реинжиниринга любой сложности моделируется ситуация «как будет» и строятся новые карты бизнес-процессов, модели данных. В свою очередь, такой подход обеспечивает и целостность данных, целостность архитектуры предприятия, неконфликтность мероприятий по реинжинирингу. Справедливости ради отмечу, что такой серьезный уровень работы требует обязательного наличия в структуре оператора ряда специалистов, среди которых обязательно должны быть ИТ- и бизнес-архитекторы. В рамках TMF операторы-участники получают доступ к лучшим наработкам, получившим успешную практическую реализацию. Кстати, eTOM (расширенная карта процессов телеком-оператора) — также одна из лучших практик TMF.
Михаил Заборов: Я согласен с тем, что должна быть группа архитекторов, которые думают о компании как о едином целом. Это ключевой вопрос. Но при этом не очень важно, какими нотациями и инструментами они пользуются. Модель можно сделать и в Visio или в его функциональных аналогах.
Анна Бабкина: Хотела бы добавить: я считаю, что ключевым моментом является тесное взаимодействие бизнеса с архитекторами, чтобы поддерживать единое понимание целевой картины, в которой бизнес хочет оказаться в ближайшей и отдаленной перспективе. Иначе возникает ненулевой риск того, что та самая «творческая» группа архитекторов «нагенерирует» то, что окажется далеким от реальности, которую представляет себе бизнес.
Александр Сергиенко: Если бизнес не понимает, чего он хочет, компании максимум через год-два настанет конец. И никакая группа архитекторов тут не поможет.
Intelligent Enterprise: Возникает смежный вопрос — каким должен быть оптимальный штат сотрудников и кому эти сотрудники должны подчиняться? А структура формальной подчиненности уже во многом должна определять разграничение ответственности за обеспечение целостности ИТ-поддержки и ИТ-ресурса между бизнесом и ИТ…
Алексей Плотников: В зависимости от зрелости компании роль группы архитекторов бизнес-процессов может выполнять как структурно выделенное подразделение BPM, так и отдельные специалисты, совмещающие построение бизнес-процессов компании со своей основной деятельностью. При этом считаю, что наиболее оптимальным будет прямое подчинение данной группы топ-менеджменту компании. Если ИТ-службу воспринимать как полноправного партнера для бизнес-подразделений, то группа, занимающаяся разработкой архитектуры бизнес-процессов, должна напрямую взаимодействовать с ИТ-архитекторами. Такая конструкция не допустит разрыва между архитектурой бизнес-процессов и архитектурой информационных систем. Принимая во внимание, что в силу специфики своей деятельности служба ИТ связана практически со всеми бизнес-процессами компании, на нее можно возложить и техническую работу по визуализации бизнес-процессов и отработке связей между ними.
Михаил Заборов: Да, это дорога с двусторонним движением. Но, к сожалению, люди не всегда четко говорят о том, что они хотят. Иногда задачу ставит руководство. Иногда, хотя и реже, ИТ-подразделение. Но чаще в ИТ говорят, что напишут ИТ-стратегию только после того, как бизнес представит бизнес-стратегию, — и эти разговоры тянутся годами. Но все равно процессы идут, и не обязательно сверху вниз. Изменение процессов может происходить из-за того, что появилось, скажем, новое требование регулятора, или из-за чего-то еще. И тут появляется какой-то человек или группа людей — архитектурное ядро, и эти изменения, идущие с разных сторон, как-то интегрирует и создает целостную модель, в том числе и на уровне ИТ. По мере необходимости оно общается с бизнесом, добиваясь нужных решений, или просто исполняет его решения, или действует полностью самостоятельно. Все зависит только от конфигурации процесса принятия решений в той или иной компании. В любом случае это архитектурное ядро должно быть. А где оно будет, не важно.
Intelligent Enterprise: Каковы типичные сценарии, приводящие к противоречиям в ИТ-поддержке бизнеса? И какие сценарии разрешения этих противоречий необходимо использовать, технические или организационные?
Александр Сергиенко: Мне кажется, мы уже дали ответ на этот вопрос: рассматривать предприятие с точки зрения архитектурного подхода. Это единственно возможный вариант из тех, что мне известны. И тут в первую очередь встает вопрос использования лучших практик и референсных моделей — своих для каждой отрасли. Для телекомов, разработчиков ПО, интеграторов, как я уже говорил, — это NGOSS и его составные части: референсная карта бизнес-процессов eTOM, технологически нейтральная архитектура и т. д. Референсные модели тем и хороши, что при необходимости их можно кастомизировать под нужды любой компании, причем совсем не обязательно делать это сразу в полном объеме по всем направлениям, можно идти шаг за шагом, поэтапно. Такие мероприятия в том числе повышают уровень зрелости компании.
Евгений Колесников: У разных типов бизнеса разные риски, разная степень динамичности, разная степень доходности. Причем доходность возникает из увеличенного риска, связанного с появлением нового рынка или с территориальным расширением компании. В случае вертикального бизнеса — да, архитектор нужен. Равно как и большой объем консалтинговых услуг для формирования процессов, которые покрывают узкую сферу деятельности, но тем не менее приносят значительный доход.
С бизнесами, не связанными с производством, например, медийным или сервисным, возникает большая проблема. Чтобы расти, нужно уметь поднимать маржинальность за счет больших объемов. И тут могут принести пользу те данные, которые другие отбрасывают. Но надо научиться их верифицировать.
Именно они могут составить ту тонкую ткань, которая позволит получить дополнительную прибыль. Или даже создать новый рынок, который можно легко монетизировать. Для этого годятся и не вполне достоверные данные, но в большом объеме и с хорошей обратной связью, что, кстати, непросто сочетать. Тут первым делом приходит на ум модное слово «краудсорсинг». Но когда в такой системе количество людей превысит некий предел, сбор информации и обратной связи становится трудноразрешимой задачей. Ведь сколько компаний потеряли управляемость при переходе через некий барьер роста! И всё потому, что ни бизнес, ни ИТ-служба не смогли поменять философию по мере этого самого роста.
На стабильном рынке при прочно занятой нише да, можно позвать архитектора. Но на рынке, который растёт, этот подход не будет работать.
Михаил Заборов: Действительно, есть ситуации, когда нужно завоевывать рынок, и тут не до архитектуры. С ИТ, без ИТ — не важно. И тут возможны два варианта. В одном случае архитекторы должны успевать за изменениями «с колес», чему есть примеры. Второй вариант: отложить выстраивание этих процессов до того момента, когда экспансия закончится и придет пора повышать эффективность бизнеса. Но есть риск, что бизнес может не дожить до этого.
Евгений Колесников: Любая новая экономика занимает определенный объем, который можно с некоторой точностью определить. Известно, какие технологии будут при этом замещены и какова возможная емкость рынка. Но скорость роста этого рынка не известна, а он может быть как постепенным, так и взрывным. И если на такой фазе привлекать архитектора, то очень велик риск ошибок: можно или не успеть, или вложить деньги в нечто бесперспективное. Надо выйти на некое плато эффективности. И только потом привлекать архитектора, чтобы выйти на некий объем и повысить маржинальность. Иначе сложно добиться выделения средств.
Михаил Заборов: Но в отсутствие архитектора в период бурного роста есть риск нарушить структуру бизнес-процессов. При этом можно создать простую или даже примитивную систему, которая будет обрабатывать две-три аналитики. Но это время рано или поздно закончится. Запас прочности у такой конструкции небольшой.
Ни один бизнес сейчас без ИТ не обходится. А когда речь идет о высокотехнологичном бизнесе, то тем более. Иначе невозможно быть уверенным в том, что ваш медийный продукт вообще дойдет до потребителей. Причем это нужно уже на стадии стартапа. И архитектура решения должна быть масштабируемой. А то как бы не оказаться в ситуации владельца той лошади из анекдота, которая «не шмогла»…
Александр Сергиенко: Хочу оппонировать позиции Михаила. Мы не говорим, что надо использовать процессный подход на всех этапах развития компании, даже если реализуется стартап. При этом под стартапом я понимаю и новую компанию, созданную с нуля для развития бизнеса, и уже существующую, задумавшую реализовать проект развития какого-либо бизнеса с нуля. И вот для стартапов, как правило, используется не процессный, а проектный подход. Ведь надо достигнуть конкретных результатов, захватить рынок. Тут процессный подход с его «делай раз, делай два, делай три» не совсем эффективен, поскольку при реализации стартапа слишком высок уровень неопределенности. Процессный подход работает только тогда, когда имеешь дело с рутиной, когда всё определенно. Но на стадии стартапа надо быть самоубийцей, чтобы его применять, это приведет к потере времени, а значит, и потенциальной доли рынка, денег в конце концов. Вместе с тем, если в проектной команде не будет архитектора, кто сможет представить целостные данные по реализации ваших планов? Никто. Этим придется заниматься самому руководителю проекта. И тогда вы обречены, в ваших сутках будет 25 часов, и вас не будут видеть ни семья, ни друзья, и это при том, что за скобками остается вопрос вашей компетенции в указанной предметной области знаний.
Алексей Плотников: А какие основания дают нам полагать, что ниша, которую занимает наш стартап, является пустой? Что, есть какая-то статистика, которую кто-то где-то собрал?
Евгений Колесников: Рынок стартапов является такой же индустрией со своими подходами. Их можно сравнить с теми, которые используют девелоперы. Там используется другая модель целостности данных, она статистическая и строится на основе обработки больших массивов данных.
Александр Сергиенко: Мы сейчас пытаемся во многом предсказать требования к информационному ресурсу завтрашнего дня. Но есть классические проверенные модели. Например, модель Захмана, которая позволяет работать с данными на разных уровнях управления компанией. Ее использование существенно улучшает процессы взаимодействия специалистов разных уровней, разных функциональных подразделений (управленцы, ИT, продажи и т. д.). Зачастую именно отсутствие в компании единого глоссария терминов приводит к тому, что каждая группа специалистов говорит на своем языке, понятном только им и не совсем понятном всем остальным. В такой ситуации целостность разрушается, и это порождает массу сложностей. Модель Захмана позволяет минимизировать указанные сложности.
Евгений Колесников: Это довольно старая модель. Есть, конечно, ниши, для которых она подходит, но рекомендовать ее всем я не стал бы. Появились качественно новые инструменты.
Я когда веду курс, то сначала спрашиваю, кто отвечает за справочники в компании. Обычно дается ответ: мы. А кто отвечает за их содержание? ИТ-директор. А если не ИТ-директор, то отвечает генеральный директор, который в этих справочниках точно ничего не понимает. Но если он вовремя не получит отчет, то виноваты будете вы. И в этом самый большой вопрос. Нет понимания, что за целостность данных отвечает CIO или тот, кто над ним. Можно написать массу регламентов, которые описывают процесс правильного ввода данных, но невозможно оставить открытым вопрос об ответственности. Хотя 80—90% тех, кто считает себя CIO, полагают, что содержательная проблема целостности данных находится вне их компетенции.
Михаил Заборов: Хотел бы прояснить тему целостности. Возьмем, например, социальную сеть. Там целостность данных абсолютно не важна, и никакие справочники тут не нужны. Зато важно сделать быстро. Но для корпоративной учетной системы такие методы не подходят. Каталог товаров в торговой сети должен быть единым, потому что продавать то, чего там нет, нельзя.
Евгений Колесников: Есть там справочники, хотя они сделаны в непривычной форме. И не стоит забывать, что существует так называемый котловой учет. Он обходится приблизительно на треть дороже традиционного, но на это идут, потому что лучше иметь котловой учет, чем никакого.
Александр Сергиенко: Да, есть ситуации, когда котловой учет допустим, равно как и лоскутная автоматизация.
Михаил Заборов: Можно провести аналогию с личными доходами. Интересна ли их величина с точностью до копейки или с точностью плюс-минус сто тысяч рублей? Если у вас столько денег, что более или менее точная цифра неважна, то вам просто не нужен этот учет. Более того, он вреден, поскольку связан с затратой ресурсов. Так же и целостность данных нужна не ради самой целостности.
Но есть много случаев, когда она все равно нужна. Возьмем, например, банк, который зарабатывает быстрые деньги за счет кредитов, депозитов. Предложим им отказаться от целостности, проще говоря, не вести учет выданных денег. Да они просто прогорят, причем быстро.
Евгений Колесников: Для банка главное — его основной капитал, лицензия и соответствие требованиям регуляторов. Это и есть банк. Работа с потребительскими кредитами — лишь часть баланса, причем обычно небольшая.
Алексей Плотников: Но и тому же банку не важны целостность и полный учет в тот момент, когда новый продукт выводится на рынок. Совсем не обязательно получать информацию по всей целевой аудитории, достаточно лишь относительно небольшого среза, чтобы понять, выводить продукт или нет. Ведь целостность — это еще и дорого. По процессам, по деньгам, по трудозатратам. Это напрямую относится к вопросу о зависимости требований к целостности от постановки конкретной бизнес-задачи.
Александр Сергиенко: В таком случае, коллеги, может быть, имеет смысл вводить несколько определений целостности? Видимо, целостность может быть полная, теоретически достижимая, которая охватывает все данные, и, например, рациональная, о которой мы сейчас и говорим. Рациональная затрагивает лишь основные бизнес-процессы, и поэтому она может быть определяющей для зарабатывания прибыли компанией. О достижении же теоретической целостности можно говорить, наверное, только в крупных компаниях, которые могут позволить себе такое дорогое удовольствие.
Евгений Колесников: При этом обеспечение целостности везде, где можно ее достичь, может создавать дополнительные трудности, съедать ресурсы, а значит, будет мешать бизнесу зарабатывать деньги.
Михаил Заборов: Это не совсем так: есть и такие задачи учета, где нет никаких денег. Например, учет опасных отходов — химических, радиоактивных, биологических. Их утилизацией занимаются госструктуры, которые не зарабатывают деньги, а наоборот, тратят их. Но тут важно, чтобы ничего не пропало. Нужна абсолютно исчерпывающая и достоверная информация, где что находится.
Евгений Колесников: На поддержание целостности нужно тратить ресурсы. Если ресурсы берутся из воздуха, то вопросов нет. Но когда поток этих средств иссякнет, целостность будет нарушаться. А в один прекрасный момент некому будет спрашивать, некому будет и отвечать.
Сергей Костяков: Целостность не всегда определяется деньгами. Должен быть какой-то запас. Ведь отсутствие целостности — это в любом случае риски, а то и прямые убытки.
Александр Сергиенко: Продолжу свою мысль. Рациональная целостность может иметь две тенденции: стремиться к нулю либо к полной целостности. Выдвину гипотезу, что одна из задач ИT-отдела заключается в создании для бизнеса возможности перехода от рациональной целостности к полной. Например, сегодня нам высокий уровень целостности не нужен, но нет никакой гарантии, что он не понадобится завтра. Есть такие области, где изначально полная целостность важна. Например, область НИОКР, где отсутствие полной целостности (в том числе по предыдущим исследованиям) означает просто крах, невозможность развития улучшений. Нужно иметь полноценный архив того, что было сделано и как. Иначе у нас по-прежнему будут падать спутники и страна будет продолжать утрачивать технологии. Здесь проявляется эффект отсроченного спроса на целостность, но спрос остается. Поэтому какое-то время (и мы это, живя в России, сейчас прекрасно понимаем) можно ничего не разрабатывать, а жить старым багажом. Но рано или поздно такая жизнь закончится.
Михаил Заборов: О целостности можно говорить только применительно к структурируемым данным. И далеко не всегда ту же научную информацию легко свести к структурируемой. Это очень сложная и трудоемкая задача. Причём есть риск того, что у двух разных людей получатся совершенно разные результаты структуризации.
Евгений Колесников: Многие виды данных можно структурировать с помощью статистических методов. Но нужно иметь некий избыток данных и время. Кроме того, значительных успехов достигли технологии разбора больших данных. Уже можно говорить о процессах самоочистки данных.
Intelligent Enterprise: Как современные технологии и подходы (аутсорсинг, облачные технологии, удаленная работа), своего рода центробежные тенденции в ИТ, влияют на качество данных?
Алексей Плотников: Эти процессы никак не противоречат централизации. Даже более того, об использовании тех же облаков и речи быть не может без консолидации ИТ-ресурсов. Децентрализованная работа с децентрализованной информацией крайне затруднительна. Да, несколько повышаются риски, но это вопрос к ИТ- и ИБ-службам.
Евгений Колесников: Мне кажется, облачные технологии никак не влияют на целостность данных. У нас одна беда: отсутствие хорошей связи за приемлемые деньги по всей территории страны.
Анна Бабкина: Не соглашусь. Количество ИТ-инструментов, используемых в организациях, увеличивается. При этом одни и те же данные используются в разных системах, и в какой-то момент в результате дополнительной обработки и преобразования «первичных» данных для целей подготовки к использованию в каком-либо бизнес-процессе они могут разойтись с системой-источником. А когда будут сформированы отчеты в одной и в другой системе, и они попадут на стол к одному руководителю, и данные в них будут различаться, то появится проблема, какой же из отчетов содержит корректные данные.
Михаил Заборов: То, что одни и те же данные используются в двух и более системах, проблемой не является. Проблема возникает тогда, когда на эти данные опираются критичные бизнес-процессы. И тут возникает задача определить, какие именно данные надо использовать для каждого конкретного процесса.
Алексей Плотников. Мне кажется, это не вполне реалистичный сценарий. Тем более, что уровень достоверности данных, которые выдают системы прогнозного планирования, и так весьма условен. Так что тут скорее стоит задача избавления от зоопарка разных систем. Ну а если данные используются в критичных бизнес-процессах, то это вопрос к архитектору. Его задача и состоит в том, чтобы определить, какой именно источник данных считать достоверным. Да, сейчас технологии автоматизации сложные и многоуровневые, и данные на выходе одной из систем вполне могут быть входными для другой. Но всё это решаемо на уровне архитектуры. И все потенциально проблемные участки легко можно выявлять и устранять.
Михаил Заборов: Не всё так просто. Бизнес-процессы даже внутри одной отрасли могут различаться кардинально. Например, ситуации в торговых компаниях, одна из которых продает консервы, а другая — дизайнерскую одежду и обувь. У них будут совершенно разные карты процессов.
