+7 499 350 77 10
+7 499 322 88 70
+7 499 322 88 70
Александр Кварцхава
Данные как основа цифрового менеджмента
Повышаем эффективность работы компании
Введение
Цифровизация шагает по стране. Информационное поле вокруг нас постоянно резонирует об этом: СМИ, выступления чиновников, разговоры бизнесменов, консорциумы, связанные с IT. Цифровизация стала нашей обыденностью, да и корпоративная архитектура перестала быть «чёрной магией».
Роль Enterprise-архитектора в крупных компаниях наконец-то признана. Её значимость, важность и ценность в корпоративной архитектуре понятна собственникам бизнеса и CEO (Chief Executive Officer или главный исполнительный директор).
Благодаря корпоративной архитектуре в практику бизнеса возвращается системная инженерия.
Но у этих явлений есть несколько ключевых последствий:
Роль Enterprise-архитектора в крупных компаниях наконец-то признана. Её значимость, важность и ценность в корпоративной архитектуре понятна собственникам бизнеса и CEO (Chief Executive Officer или главный исполнительный директор).
Благодаря корпоративной архитектуре в практику бизнеса возвращается системная инженерия.
Но у этих явлений есть несколько ключевых последствий:
- Объёмы данных в компаниях увеличиваются. Особенно если в компаниях присутствуют типовые решения, вроде 1С: ERP, SAP: ERP и других ERP систем (кастомные ERP-системы или коробочные). Увеличение идёт очень быстро, компании накапливают БД в сотни Гб и даже в Тб.
- Процессы большинства компаний по-прежнему управляются вручную, что требует множество сил менеджеров, причём именно от менеджеров верхнего звена, стоимость часа работы которых равноценна стоимости работы целого подразделения. Понять, какие решения приняты, что по ним делается, как их вырабатывали, отследить цепочку выполненных задач — это поистине титанический труд. Поэтому у топ-менеджера может быть 22 помощника и всё равно он не будет ничего успевать.
и как на этом сделать деньги для компании. Вы узнаете, почему компании, которые вложили миллионы в IT, никак не могут увидеть отдачу.
Кроме того, мы рассмотрим основные ошибки управления и сформулируем пути их решения с помощью различных практик в рамках архитектурного подхода на фундаменте фреймворка TOGAF.
Проблемы с данными в эпоху цифровизации
Компании по всему миру выделяют бюджеты, внедряют различные системы и искренне верят, что огромные массивы данных начнут приносить им миллионы. Руководители под влиянием всеобщей шумихи и историй успеха решаются на запуск новых технологических проектов, не особенно понимая, как это всё на самом деле работает.
Компании получают большое количество данных, с которыми чаще всего ни они сами, ни менеджеры компании не умеют правильно работать. Это приводит к тому, что затраты на внедрение новых систем не оправдывают себя: огромные объёмы данных копятся, не приносят компании прибыли, а, напротив, требуют затрат на хранение и обработку.
Во избежание развития подобных негативных сценариев внедрения, предлагаю рассмотреть 6 типовых проблем, которые встречаются в компаниях при работе с данными.
1. Архитектура данных в компании не прорабатывается, не проектируется, а нередко вообще отсутствует как понятие.
Компании получают большое количество данных, с которыми чаще всего ни они сами, ни менеджеры компании не умеют правильно работать. Это приводит к тому, что затраты на внедрение новых систем не оправдывают себя: огромные объёмы данных копятся, не приносят компании прибыли, а, напротив, требуют затрат на хранение и обработку.
Во избежание развития подобных негативных сценариев внедрения, предлагаю рассмотреть 6 типовых проблем, которые встречаются в компаниях при работе с данными.
1. Архитектура данных в компании не прорабатывается, не проектируется, а нередко вообще отсутствует как понятие.
Напомню, что корпоративная архитектура, с точки зрения модели TOGAF, состоит из бизнес-архитектуры, архитектуры данных, архитектуры бизнес-приложений и технологической архитектуры.
Бизнес-архитектура, в свою очередь, состоит из совокупности бизнес-ролей, процессов, организационной структуры компании.
Данные необходимы для осуществления бизнес-процессов, описанных в бизнес-архитектуре компании. Архитектура бизнес-приложений описывает бизнес-приложения, такие, например, как 1С: ERP, которые с данными работают: сохраняют, обрабатывают, визуализируют.
Архитектура данных — это один из ключевых элементов корпоративной архитектуры, поэтому довольно странно, что с ней не осуществляется никакой работы. На практике крайне редко можно встретить подробно описанную, достаточно понятную схему работы с данными. Но я считаю, что каждая средняя и уж тем более крупная компания должна иметь подробное описание того, что происходит с данными с момента их поступления в компанию и до момента, когда они перестают представлять хоть какую-то ценность.
Бизнес-архитектура, в свою очередь, состоит из совокупности бизнес-ролей, процессов, организационной структуры компании.
Данные необходимы для осуществления бизнес-процессов, описанных в бизнес-архитектуре компании. Архитектура бизнес-приложений описывает бизнес-приложения, такие, например, как 1С: ERP, которые с данными работают: сохраняют, обрабатывают, визуализируют.
Архитектура данных — это один из ключевых элементов корпоративной архитектуры, поэтому довольно странно, что с ней не осуществляется никакой работы. На практике крайне редко можно встретить подробно описанную, достаточно понятную схему работы с данными. Но я считаю, что каждая средняя и уж тем более крупная компания должна иметь подробное описание того, что происходит с данными с момента их поступления в компанию и до момента, когда они перестают представлять хоть какую-то ценность.
2. Визуализация данных рассматривается как наследство под девизом: «До меня пользовались отчётом, значит, и я буду».
Зачастую и у рядового сотрудника, и у руководителя практически отсутствует понимание, что показывает конкретный отчёт или диаграмма.
3. Культ красивых графиков и диаграмм, где оформление подменяет содержание.
В компании могут создаваться тысячи диаграмм, но при этом и у создателей, и у потребителей может отсутствовать понимание, что и для чего они отображают. И при этом со стороны менеджмента идёт поощрение «размножения» подобных диаграмм, так как они хорошо выглядят в презентации или в отчёте.
Зачастую и у рядового сотрудника, и у руководителя практически отсутствует понимание, что показывает конкретный отчёт или диаграмма.
3. Культ красивых графиков и диаграмм, где оформление подменяет содержание.
В компании могут создаваться тысячи диаграмм, но при этом и у создателей, и у потребителей может отсутствовать понимание, что и для чего они отображают. И при этом со стороны менеджмента идёт поощрение «размножения» подобных диаграмм, так как они хорошо выглядят в презентации или в отчёте.
4. Аналитическая культура не только отсутствует, но и просто откровенно презирается.
Массивы данных, которые накапливает компания, лежат мёртвым грузом. Существует мнение, что хранить данные ничего не стоит («Зачем нам эти данные? А, пусть будут!»), но это глубочайшее заблуждение. Пока данные не используются, они не только не приносят пользы, но наносят вред, так как их хранение, обработка, визуализация и прочие операции стоят денег. То есть работа с данными по умолчанию будет убыточным проектом, если вы не будете их использовать.
5. Используются коробочные решения без кастомизации под нужды компании
В результате внедрения коробочных решений компания получает множество ненужных ей данных. Если вы сейчас откроете систему CRM в вашей компании, то увидите огромное количество хранящихся в ней данных. Очень велика вероятность, что никто в компании не сможет чётко объяснить, как будут использованы эти данные.
Массивы данных, которые накапливает компания, лежат мёртвым грузом. Существует мнение, что хранить данные ничего не стоит («Зачем нам эти данные? А, пусть будут!»), но это глубочайшее заблуждение. Пока данные не используются, они не только не приносят пользы, но наносят вред, так как их хранение, обработка, визуализация и прочие операции стоят денег. То есть работа с данными по умолчанию будет убыточным проектом, если вы не будете их использовать.
5. Используются коробочные решения без кастомизации под нужды компании
В результате внедрения коробочных решений компания получает множество ненужных ей данных. Если вы сейчас откроете систему CRM в вашей компании, то увидите огромное количество хранящихся в ней данных. Очень велика вероятность, что никто в компании не сможет чётко объяснить, как будут использованы эти данные.
6. При покупке кастомизированных решений компания включает все доступные опции, даже если на самом деле они ей не нужны
Функциональная опция — это альтернативная функциональность, который можно включить или выключить. Однако руководство, ввиду того, что платит большие деньги, считает необходимым использовать все опции, совершенно не подозревая, что это может нанести вред компании.
Функциональная опция — это альтернативная функциональность, который можно включить или выключить. Однако руководство, ввиду того, что платит большие деньги, считает необходимым использовать все опции, совершенно не подозревая, что это может нанести вред компании.
Мифы о данных
Помимо проблем существуют расхожие мифы о данных, зарождение которых часто обусловлено некомпетентностью менеджеров. Зачастую проблемы базируются на мифах, а иногда — наоборот.
Миф № 1: Все данные в систему вводятся своевременно, полностью и достоверно.
К сожалению, в реальности это далеко не так. Чтобы добиться качественного выполнения этих трёх аспектов требуется высокий уровень управленческой дисциплины в компании. Но, если вы не стремитесь к выполнению этих трех аспектов внесения данных, то будьте готовы к тому, что ГБ или Тб данных, которые у вас хранятся, не просто бесполезны, а нанесут вред, поскольку могут быть использованы в аналитической деятельности и послужат причиной принятия неверных решений.
Миф № 1: Все данные в систему вводятся своевременно, полностью и достоверно.
К сожалению, в реальности это далеко не так. Чтобы добиться качественного выполнения этих трёх аспектов требуется высокий уровень управленческой дисциплины в компании. Но, если вы не стремитесь к выполнению этих трех аспектов внесения данных, то будьте готовы к тому, что ГБ или Тб данных, которые у вас хранятся, не просто бесполезны, а нанесут вред, поскольку могут быть использованы в аналитической деятельности и послужат причиной принятия неверных решений.
Миф № 2: Существует чёткое понимание, какая информация нужна ответственным сотрудникам для анализа деятельности компании.
Когда ты приходишь на проект и поднимаешь этот вопрос, все делают вид, что это очевидно. Однако, за «очевидно» обычно нет никакой конкретики: ни документов, ни регламентов — ничего. Единственный верный выход в таких ситуациях — просить представителей компании расписать на бумаге, какая информация им нужна для анализа.
Миф 3: Всегда ясно, в каких приложениях вносить данные, сохранять, обрабатывать и визуализировать.
Когда ты приходишь на проект и поднимаешь этот вопрос, все делают вид, что это очевидно. Однако, за «очевидно» обычно нет никакой конкретики: ни документов, ни регламентов — ничего. Единственный верный выход в таких ситуациях — просить представителей компании расписать на бумаге, какая информация им нужна для анализа.
Миф 3: Всегда ясно, в каких приложениях вносить данные, сохранять, обрабатывать и визуализировать.
Очень часто IT-служба подменяет понятия работы с данными на работу с бизнес-приложениями. Например, IT-служба говорит о том, что 1С в компании работает, то есть запускается. Это значит, что пользователи 1С могут вносить документы, а остальное IT-службу не заботит. В данном случае напрочь отсутствует критический подход к оценке вносимых данных со стороны IT-службы: её не волнует, что в ПО вносятся недостоверные данные, пользователи просматривают эти данные, именно эти данные идут в отчёты. Бизнес перекладывает ответственность за этот процесс на IT, а IT — на бизнес. В итоге ответственность за проблему архитектуры данных и аналитическую культуру никто на себя не берёт. Проблема недостоверности данных остается нерешённой.
Миф 4: Очень легко определить, какими данными будут обмениваться приложения.
На самом же деле проектировать обмен, то есть интеграцию — долго и дорого. Дело в том, что обмен может проектироваться неделями, разрабатываться ещё дольше и в итоге стать очень дорогим удовольствием, особенно если системы имеют разное ядро или разную платформу. В качестве примера можно привести настройку обмена данными между SAP и 1C.
Миф 5: Аналитика осуществляется сама собой. Никаких отдельных ролей или регламентов не нужно.
К сожалению, если процессом аналитической деятельности не управлять, предварительно его спроектировав, то никакой аналитики у вас и не будет. Даже если сотрудники знают, как вносить данные, они могут вносить их, например, несвоевременно или не полностью. Да и анализировать данные тоже сам по себе никто не начнёт.
На самом же деле проектировать обмен, то есть интеграцию — долго и дорого. Дело в том, что обмен может проектироваться неделями, разрабатываться ещё дольше и в итоге стать очень дорогим удовольствием, особенно если системы имеют разное ядро или разную платформу. В качестве примера можно привести настройку обмена данными между SAP и 1C.
Миф 5: Аналитика осуществляется сама собой. Никаких отдельных ролей или регламентов не нужно.
К сожалению, если процессом аналитической деятельности не управлять, предварительно его спроектировав, то никакой аналитики у вас и не будет. Даже если сотрудники знают, как вносить данные, они могут вносить их, например, несвоевременно или не полностью. Да и анализировать данные тоже сам по себе никто не начнёт.
Как правильно анализировать данные. Классификация аналитики данных
Анализ данных помогает менеджерам повысить качество принимаемых решений. Работая с данными, менеджер должен осознавать, какого рода аналитика его интересует, поскольку от правильно заданного вопроса напрямую зависит полученный результат. В связи с тем, что среди менеджеров существует огромное количество заблуждений и вопросов, связанных с аналитикой, не лишним будет подробно разобрать классификацию аналитики данных.
Итак, аналитика данных подразделяется на следующие виды:
- Описательная (дескриптивная), которая отвечает на вопрос «Что случилось?»
- Диагностическая, которая анализирует информацию, чтобы ответить на вопрос «Почему это случилось?»
- Предиктивная (прогнозная, предсказательная), которая прогнозирует неизвестные события в будущем, отвечая на вопрос «Что может случиться?»
- Предписывающая (предписательная), которая отвечает на главный управленческий вопрос «Что делать чтобы события развивались нужным нам путём?»
Описательная аналитика ответит нам, что за прошлый месяц было продано 5 тонн яблок сорта, А и 500 кг яблок сорта Б.
Также описательная аналитика может нам дать информацию о нашем магазинчике в самых разных разрезах: на какую сумму было продано, было продано больше яблок или апельсинов, овощей или фруктов, сколько дней магазин не работал в прошлом месяце, как долго отсутствовал сотрудник по причине болезни — всё это конкретная фиксация событий в прошлом.
Диагностическая аналитика ответит нам, почему мы продали яблок сорта, А в 10 раз больше, чем яблок сорта Б.
Возможно сорт, которого продали меньше, всё ещё лежит на прилавке и на складе. Яблоки этого сорта оказались кислыми, а клиенты хотели покупать сладкие яблоки. Изучив сорт кислых яблок, мы узнали, что сладкими они станут только через 2 месяца. А значит, поставщик сорвал из зелеными, привёз, а мы их купили по незнанию.
Важно заметить, что здесь мы по-прежнему обращаемся к событиям прошлого.
Также описательная аналитика может нам дать информацию о нашем магазинчике в самых разных разрезах: на какую сумму было продано, было продано больше яблок или апельсинов, овощей или фруктов, сколько дней магазин не работал в прошлом месяце, как долго отсутствовал сотрудник по причине болезни — всё это конкретная фиксация событий в прошлом.
Диагностическая аналитика ответит нам, почему мы продали яблок сорта, А в 10 раз больше, чем яблок сорта Б.
Возможно сорт, которого продали меньше, всё ещё лежит на прилавке и на складе. Яблоки этого сорта оказались кислыми, а клиенты хотели покупать сладкие яблоки. Изучив сорт кислых яблок, мы узнали, что сладкими они станут только через 2 месяца. А значит, поставщик сорвал из зелеными, привёз, а мы их купили по незнанию.
Важно заметить, что здесь мы по-прежнему обращаемся к событиям прошлого.
Предиктивная аналитика расскажет нам, что может случиться в будущем. В качестве примера можно привести прогноз продаж на следующий месяц.
Мы уже сейчас планируем, что будем закупать, но пока не знаем, что ждёт нас в будущем. И тут мы задаем себе вопрос: «А что может случиться?». Например, могут резко вырасти продажи фруктов, в частности цитрусовых. Данный прогноз должен быть основан на ряде объективных причин: жаркое лето, увеличение урожайности и так далее.
Предписывающая аналитика отвечает на вопрос, адресованный непосредственно к бизнесу «Что мы будем делать, чтобы события развивались нужным нам путём?». Что мы должны сделать, чтобы увеличить свою выручку в следующем месяце? Что мы должны сделать, чтобы быть готовыми к резкому росту продаж цитрусовых? Исходя из полученных данных, мы можем сделать вывод, что нам необходимо закупить больше цитрусовых в следующем периоде, чтобы достичь поставленных целей.
Мы уже сейчас планируем, что будем закупать, но пока не знаем, что ждёт нас в будущем. И тут мы задаем себе вопрос: «А что может случиться?». Например, могут резко вырасти продажи фруктов, в частности цитрусовых. Данный прогноз должен быть основан на ряде объективных причин: жаркое лето, увеличение урожайности и так далее.
Предписывающая аналитика отвечает на вопрос, адресованный непосредственно к бизнесу «Что мы будем делать, чтобы события развивались нужным нам путём?». Что мы должны сделать, чтобы увеличить свою выручку в следующем месяце? Что мы должны сделать, чтобы быть готовыми к резкому росту продаж цитрусовых? Исходя из полученных данных, мы можем сделать вывод, что нам необходимо закупить больше цитрусовых в следующем периоде, чтобы достичь поставленных целей.
Резюмируем, аналитика данных состоит из:
- Фиксации прошлого
- Анализа прошлого
- Прогноза будущего
- Формирования плана будущих действий
Проблемы цифрового менеджмента
Существуют управленческие проблемы, которые присущи современным организациям практически любого размера. С ростом масштаба деятельности они только усиливают своё влияние на эффективность системы управления. И чем меньше внимания уделяется проблемам менеджмента в организации, тем менее эффективна её система управления.
Отсутствие потока решений в рамках высокоуровневого эталона.
Менеджмент — это не решение каждой из возникающих проблем в отдельности, это анализ имеющейся ситуации, создание эталона, так называемого регламента, и жизнь подразделений компании по этому эталону. К сожалению, основной проблемой менеджмента компании становится как раз тот факт, что в компании нет потока решений, есть только куча разорванных событий с ручной фиксацией в электронной почте или даже на бумаге, которая нередко оказывается мусорной корзине.
Отсутствие потока решений в рамках высокоуровневого эталона.
Менеджмент — это не решение каждой из возникающих проблем в отдельности, это анализ имеющейся ситуации, создание эталона, так называемого регламента, и жизнь подразделений компании по этому эталону. К сожалению, основной проблемой менеджмента компании становится как раз тот факт, что в компании нет потока решений, есть только куча разорванных событий с ручной фиксацией в электронной почте или даже на бумаге, которая нередко оказывается мусорной корзине.
Отсутствуют истории выработки управленческих решений, а также принятия и контроля результатов по ним.
Жизнь компании состоит из множества внутренних и внешних событий. Поэтому уже через 5−10 дней никто не вспомнит, что было принято на последнем совещании, или у каждого останутся противоречащие друг другу воспоминания. Что уж говорить о контроле и обеспечении ресурсами в отсутствие истории, это просто невозможно.
Совещания собираются вручную, без конкретной привязки к рабочему графику участников.
Нередко случается ситуация, когда секретарь генерального директора бегает по подразделениям и пытается создавать всех руководителей подразделений в совещательную комнату к директору. Это пустая трата времени, которая к тому же рождает хаос.
Важно помнить, что ни у одного сотрудника компании нет бесплатного рабочего времени. А потери этого времени могут достигать в таких ситуациях до 60−70%, превращаясь бесконечные переработки, которые демотивируют менеджеров, и они выгорают. Также компания несёт неоправданные убытки, если переработки необходимо оплачивать. К слову, гонорары у управленцев довольно высокие.
Жизнь компании состоит из множества внутренних и внешних событий. Поэтому уже через 5−10 дней никто не вспомнит, что было принято на последнем совещании, или у каждого останутся противоречащие друг другу воспоминания. Что уж говорить о контроле и обеспечении ресурсами в отсутствие истории, это просто невозможно.
Совещания собираются вручную, без конкретной привязки к рабочему графику участников.
Нередко случается ситуация, когда секретарь генерального директора бегает по подразделениям и пытается создавать всех руководителей подразделений в совещательную комнату к директору. Это пустая трата времени, которая к тому же рождает хаос.
Важно помнить, что ни у одного сотрудника компании нет бесплатного рабочего времени. А потери этого времени могут достигать в таких ситуациях до 60−70%, превращаясь бесконечные переработки, которые демотивируют менеджеров, и они выгорают. Также компания несёт неоправданные убытки, если переработки необходимо оплачивать. К слову, гонорары у управленцев довольно высокие.
Принятие решений носит характер интуитивных допущений.
Если менеджеры не проводят качественную аналитику, то они не способны принять обоснованное решение. Поэтому нередко можно услышать высказывания, не имеющие никакого объяснения или обоснования: «я знаю», «я чувствую», «мы сможем», «давайте так сделаем», «давайте добавим денег» или «убавим денег».
Если менеджеры не проводят качественную аналитику, то они не способны принять обоснованное решение. Поэтому нередко можно услышать высказывания, не имеющие никакого объяснения или обоснования: «я знаю», «я чувствую», «мы сможем», «давайте так сделаем», «давайте добавим денег» или «убавим денег».
Мифы о менеджменте
На основе проблем формируются мифы о менеджменте, в которые охотно верят менеджеры компаний. Важно отметить, что сейчас речь пойдёт не о какой-то конкретной компании, а о большом количестве компаний, которые имеют все необходимые системы (1С:ERP, Битрикс24 и даже CRM-систему), но несмотря на это верят в мифы и, как результат, имеют большие проблемы с менеджментом.
Миф № 1: Написанный регламент всегда исполняется сотрудниками, а процессы всегда управляемы.
В подавляющем большинстве случаев на написанный регламент просто игнорируется, если нет инструментов его цифровизации, управления и исполнения.
Миф № 1: Написанный регламент всегда исполняется сотрудниками, а процессы всегда управляемы.
В подавляющем большинстве случаев на написанный регламент просто игнорируется, если нет инструментов его цифровизации, управления и исполнения.
Миф № 2: Все имеющиеся данные автоматически превращаются в информативные отчёты, а они в свою очередь в качественную аналитику.
Проблема в том, что если отчёты никак не используются, например, для формирования будущих закупок продукции, то сами они не появятся. Единственный вариант, когда отчёты формируются «автоматически»: если в компании есть отдельно взятый сотрудник, который, собственно, и будет заниматься формированием этих отчётов.
Миф № 3: Менеджеры, которые ранее принимали решения на интуиции, столкнувшись с цифровизацией, начнут сами ставить задачи на формирование отчётов, проводить анализ и принимать управленческие решения на основе аналитики.
Как бы нам этого не хотелось, сами менеджеры не перестроятся, не начнут вдруг анализировать данные и принимать решения опираясь исключительно на различные виды аналитики. Чтобы это произошло, нужно проделать большую работу по обучению этих людей.
Проблема в том, что если отчёты никак не используются, например, для формирования будущих закупок продукции, то сами они не появятся. Единственный вариант, когда отчёты формируются «автоматически»: если в компании есть отдельно взятый сотрудник, который, собственно, и будет заниматься формированием этих отчётов.
Миф № 3: Менеджеры, которые ранее принимали решения на интуиции, столкнувшись с цифровизацией, начнут сами ставить задачи на формирование отчётов, проводить анализ и принимать управленческие решения на основе аналитики.
Как бы нам этого не хотелось, сами менеджеры не перестроятся, не начнут вдруг анализировать данные и принимать решения опираясь исключительно на различные виды аналитики. Чтобы это произошло, нужно проделать большую работу по обучению этих людей.
Миф № 4: Историю в письменном виде вести не надо, так как все и всё хорошо помнят, даже спустя 2−3 года.
Интересно, что это пожалуй одно из самых больших заблуждений, с которым приходится бороться. Зачастую ведение истории совещаний, например, в Битрикс 24 вызывает у людей агрессию: они считают, что тратят своё время впустую. Но при этом, всё те же люди тратят недели на поиск протокола совещания, если он вообще был.
Интересно, что это пожалуй одно из самых больших заблуждений, с которым приходится бороться. Зачастую ведение истории совещаний, например, в Битрикс 24 вызывает у людей агрессию: они считают, что тратят своё время впустую. Но при этом, всё те же люди тратят недели на поиск протокола совещания, если он вообще был.
Как принимать решения на основе данных
Итак, мы разобрали проблемы, которые возникают в результате некомпетентности менеджеров, и мифы основанные на этих проблемах. Осталось понять, как стоит действовать, чтобы избежать возникновения этих проблем.
Начнем с того, что решение проблем — это полноценный архитектурный проект, по полному циклу Architecture Development Method (ADM). А нередко такой проект приходится реализовывать уже после того, как в компании были внедрены системы ERP, CRM, CPM, PDM и другие. Но, разумеется, все проблемы с менеджментом необходимо решать до внедрения каких-либо систем. Однако, на практике приходится сталкиваться с абсолютно противоположной ситуацией. Это выглядит так, будто вы пытаетесь выбрать фундамент здания, а что будете строить — небоскреб или военный полигон — ещё не решили.
Начнем с того, что решение проблем — это полноценный архитектурный проект, по полному циклу Architecture Development Method (ADM). А нередко такой проект приходится реализовывать уже после того, как в компании были внедрены системы ERP, CRM, CPM, PDM и другие. Но, разумеется, все проблемы с менеджментом необходимо решать до внедрения каких-либо систем. Однако, на практике приходится сталкиваться с абсолютно противоположной ситуацией. Это выглядит так, будто вы пытаетесь выбрать фундамент здания, а что будете строить — небоскреб или военный полигон — ещё не решили.
Типовой алгоритм решения проблем с менеджментом включает следующие этапы:
- Создание архитектурного видения
- Согласование архитектурного видения со всеми заинтересованными лицами
- Проработка трёх уровней архитектуры: технологическая архитектура, архитектура данных, бизнес-архитектура
Скажем несколько слов о проблемах, возникающих на шаге три (проработка трёх уровней архитектуры).
1. В процессе проработки корпоративной архитектуры проблемы чаще всего возникают в архитектуре бизнес-процессов.
Из этого следует, что необходимо полностью формализовать бизнес-архитектуру компании: описать все процессы, роли, функции, сервисы. На этапе формализации бизнес-требований необходимо определить ключевые точки принятия решений и необходимую для этого аналитику.
2. Множество ошибок совершается также при проектирование архитектуры данных и способов её представления.
Если компания приобретает, например, 1С: ERP, в которую уже заложена определённая модель данных, то менеджеры компании считают, что это одно целое и пытаются адаптировать свою архитектуру данных под приложение. В результате складывается такая ситуация, когда адекватное проектирование архитектуры данных в компании вообще отсутствует. В этом и кроется основная проблема! Архитектура данных должна выстраиваться под бизнес-процессы конкретной компании и, впоследствии, обеспечивать все подразделения именно теми данными, которые необходимы для осуществления этих бизнес-процессов. Поэтому, чтобы достичь успеха в проектировании архитектуры данных необходимо в процессе проектирования архитектуры данных опираться на бизнес-процессы, а не на архитектуру бизнес-приложений.
Из этого следует, что необходимо полностью формализовать бизнес-архитектуру компании: описать все процессы, роли, функции, сервисы. На этапе формализации бизнес-требований необходимо определить ключевые точки принятия решений и необходимую для этого аналитику.
2. Множество ошибок совершается также при проектирование архитектуры данных и способов её представления.
Если компания приобретает, например, 1С: ERP, в которую уже заложена определённая модель данных, то менеджеры компании считают, что это одно целое и пытаются адаптировать свою архитектуру данных под приложение. В результате складывается такая ситуация, когда адекватное проектирование архитектуры данных в компании вообще отсутствует. В этом и кроется основная проблема! Архитектура данных должна выстраиваться под бизнес-процессы конкретной компании и, впоследствии, обеспечивать все подразделения именно теми данными, которые необходимы для осуществления этих бизнес-процессов. Поэтому, чтобы достичь успеха в проектировании архитектуры данных необходимо в процессе проектирования архитектуры данных опираться на бизнес-процессы, а не на архитектуру бизнес-приложений.
3. Далее, на этапе внедрения бизнес-приложения, необходимо постоянно спрашивать себя: «А соответствует ли оно вашей архитектуре данных или в него нужно что-то добавить/убрать?» То есть, по сути, это этап перепроектирования системной архитектуры компании под аналитическую деятельность, которую также необходимо выстроить.
Связь архитектуры системы и контура управления
Для того, чтобы компания развивалась, необходимо выстраивать связь между архитектурой системы и контуром управления. Контур управления — это система управления бизнесом, основанная на совокупности точек принятия решений.
Давайте подробнее посмотрим, как данная связь может быть организована, на модели.
Давайте подробнее посмотрим, как данная связь может быть организована, на модели.
Модель связи архитектуры системы и контура управления
Будем подниматься по блокам модели, указанной на рисунке, снизу вверх.
Блоки технологическая архитектура и архитектура бизнес-приложений — это учётные системы различного типа, генерирующие данные, на основе которых мы можем принимать решения. Эти блоки проектируем в первую очередь.
Далее необходимо спроектировать архитектуру данных так, чтобы было возможным осуществлять аналитическую деятельность, поскольку всякая аналитическая деятельность опирается на данные. Аналитическую деятельность мы выстраиваем так, чтобы система управления бизнесом, то есть контур управления, работал.
А контур управления состоящий, в свою очередь, из огромного количества точек принятия решений связанных друг с другом, должен поддерживать бизнес-процессы компании.
Блоки технологическая архитектура и архитектура бизнес-приложений — это учётные системы различного типа, генерирующие данные, на основе которых мы можем принимать решения. Эти блоки проектируем в первую очередь.
Далее необходимо спроектировать архитектуру данных так, чтобы было возможным осуществлять аналитическую деятельность, поскольку всякая аналитическая деятельность опирается на данные. Аналитическую деятельность мы выстраиваем так, чтобы система управления бизнесом, то есть контур управления, работал.
А контур управления состоящий, в свою очередь, из огромного количества точек принятия решений связанных друг с другом, должен поддерживать бизнес-процессы компании.
Точка принятия решения — это то место в бизнес-процессе компании, в котором требуется принять управленческое решение. Непосредственно в этой точке запускается выполнение всех последующих действий.
Допустим, перед вами стоит задача оценить эффективность производственной линии предприятия. Используя в качестве инструмента данные (загруженность линии, количество поломок на линии в месяц и другие), вы можете принять управленческое решение. Оно может заключаться, например, в масштабировании производственной линии или, напротив, её демонтаже. Но сам факт необходимости принять такое решение говорит о том, что перед нами одна из точек принятия решения в этой компании.
Стоит заметить, что сложность контура управления зависит от того, настолько сложный контур необходим отдельно взятой компании, ведь точек принятия решений можно выделить бесконечное множество и ограничиваются они только масштабами организации.
Допустим, перед вами стоит задача оценить эффективность производственной линии предприятия. Используя в качестве инструмента данные (загруженность линии, количество поломок на линии в месяц и другие), вы можете принять управленческое решение. Оно может заключаться, например, в масштабировании производственной линии или, напротив, её демонтаже. Но сам факт необходимости принять такое решение говорит о том, что перед нами одна из точек принятия решения в этой компании.
Стоит заметить, что сложность контура управления зависит от того, настолько сложный контур необходим отдельно взятой компании, ведь точек принятия решений можно выделить бесконечное множество и ограничиваются они только масштабами организации.
Что необходимо сделать перед внедрением различного рода систем управления организацией?
Теперь давайте подробнее разберёмся с тем, что необходимо сделать перед внедрением различного рода систем управления организацией.
- Проанализировать и формализовать текущую бизнес-архитектуру компании
- Формализовать контур управления бизнесом или, иначе говоря, точки принятия решения об исполнении процессов
- Выстроить под контур управления аналитическую деятельность, архитектуру данных, архитектуру бизнес-приложений, технологическую архитектур
Зачем нам всё это делать? Как мы определили ранее, генерация денег или потока ценности (value chain stream) осуществляется в бизнес-процессах компании. И то, как будет обеспечено управление движением этого потока ценности, определяет контур управления компанией, то есть совокупность точек принятия решений.
В каждой из точек происходит принятие управленческих решений на основе данных — это data-driven management. То есть все системы (ERP, SRM и так далее) хранят данные и предоставляют их в красивом виде через отчёты и различного рода визуализацию, если вы, конечно, не работаете с данными напрямую. А управление движением этих данных осуществляется через систему цифрового менеджмента, Битрикс24, 1С: Документооборот и SharePoint.
Получается, что прежде, чем внедрять систему хранения и визуализации данных, необходимо обеспечить эти самые данные, то есть перевести все имеющиеся процессы в цифровой менеджмент. Только тогда можно будет увидеть всю цепочку операционной деятельности.
Если говорить про стратегическую деятельность, то при отсутствии цифровизации мы получим практически не жизнеспособную ситуацию, потому что после декомпозиции стратегии на цепочку задач, мы не сможем отследить как эти задачи исполняются.
Получается, что прежде, чем внедрять систему хранения и визуализации данных, необходимо обеспечить эти самые данные, то есть перевести все имеющиеся процессы в цифровой менеджмент. Только тогда можно будет увидеть всю цепочку операционной деятельности.
Если говорить про стратегическую деятельность, то при отсутствии цифровизации мы получим практически не жизнеспособную ситуацию, потому что после декомпозиции стратегии на цепочку задач, мы не сможем отследить как эти задачи исполняются.
Здесь крайне важно понимать, что, во-первых, данные необходимо трансформировать через аналитику. То есть выстраивается цепочка: данные проходят обработку через аналитику, а затем результаты аналитической деятельности попадают в точку принятия решений. Если нет данных, то эта цепочка нереализуема и теряется весь смысл в жёлтых квадратах (3 этапа на рисунке выше). Довольно редко случается видеть модель в которой есть жёлтые квадраты, но нет синих и зелёных, чаще всё ровно наоборот.
Очень многие компании обращающиеся с тем, что им необходимо внедрить какую-нибудь систему, и они выбирают, например, между SAP: ERP и 1C: ERP. То есть они выбирают между двумя вариантами архитектуры данных и архитектуры бизнес-приложений. Но поскольку в таких компаниях нет продуманной модели связи архитектуры системы и её контура управления, то такой выбор будет преждевременным и в данной ситуации совершенно неважным.
Сначала мы определяем, какие есть бизнес-процессы, потом выстраиваем контур управления и выясняем, как организована аналитическая деятельность. И только после этого можно поднять вопрос о том, какая нужна системная (архитектура данных, архитектура бизнес приложений) и технологическая архитектура (обслуживает системы).
Очень многие компании обращающиеся с тем, что им необходимо внедрить какую-нибудь систему, и они выбирают, например, между SAP: ERP и 1C: ERP. То есть они выбирают между двумя вариантами архитектуры данных и архитектуры бизнес-приложений. Но поскольку в таких компаниях нет продуманной модели связи архитектуры системы и её контура управления, то такой выбор будет преждевременным и в данной ситуации совершенно неважным.
Сначала мы определяем, какие есть бизнес-процессы, потом выстраиваем контур управления и выясняем, как организована аналитическая деятельность. И только после этого можно поднять вопрос о том, какая нужна системная (архитектура данных, архитектура бизнес приложений) и технологическая архитектура (обслуживает системы).
“
Сам по себе SAP не генерирует прибыль компании, зато отлично генерирует затраты на его внедрение и сопровождение.
Или, например, Битрикс24. Если вы его не используете для того, чтобы внедрить в компании цифровой менеджмент как ежедневную практику, внедряя её через архитектурный проект, через трансформацию модели управления, то он тоже не будет генерировать денег. То есть всё, чем он будет полезен — это информация из отдела кадров, о том у кого день рождения или как зовут нового сотрудника.
Вывод
Выстраивание контура управления бизнесом посредством точек принятия решений представляет собой то самое место, где сходится управление на основе данных и цифровой менеджмент: Битрикс24 и 1С: ERP. Именно через это объединение компания избегает интуитивных решений и повышает свою экономическую эффективность работы компании.
Вопросы
- Вопрос:Существует ли полный список данных, на основе которых создаётся архитектура ИС?Ответ:Универсального списка нет и быть не может. Полный список данных возможно создать, если изучить бизнес-процессы и определить как устроен контур управления конкретной компании.
Для примера можно привести компанию, в которой нет производства. Если у нас нет производства, значит совершенно не нужно в информационной системе хранить информацию о выпуске изделий, количестве брака, трудоёмкости изделий и так далее. То есть список данных напрямую зависит от процессов, которые есть в компании.
Напомню, что в компании можно выделить миллион точек принятия решений. Но в реальности их около 100−150 на всех менеджеров. То есть, если в компании 7−10 управленцев, то получается примерно 10−15 точек на одного менеджера. В каждой из этих точек для принятия решения нужны определённые данные, и как раз совокупность этих данных должна лечь в архитектуру информационной системы. - Вопрос:Зачем для архитектуры нужны данные?Ответ:Многие технические специалисты задаются подобным вопросом. Приведём простой пример. Компания РЖД. Поезда — это система, пассажиры и грузы — данные. Зачем поездам нужны пассажиры и грузы? А затем, что поезда не имеют никакого смысла, если нет пассажиров и грузов. Соответственно, 80% проблем, которые возникают у компаний с 1С: ERP связаны с данными, а не с самой системой. Теоретически можно создать систему без данных, но, так как она не будет иметь никакого смысла, то бизнес за неё платить не будет.
- Вопрос:Периодически менеджеры увлекаются оформлением дашбордов, а не содержанием информации, которую они должны предоставлять. Как в таком случае понять какую информацию надо выводить?Ответ:Менеджеры действительно очень любят играть в игру с красивыми картинками, которые никуда дальше не идут. Сейчас особенно много информационных систем, которые имеют огромное количество графиков, отчёты печатаются ИС на сотни страниц и никто их не смотрит. Зачастую оказывается так, что одному управленцу нужно всего 3−4 показателя. Следовательно, необходимо выводить менеджеров на точки принятия решений и уточнять какие данные реально необходимы, чтобы принять решение.
- Вопрос:Какие ещё подходы к проектированию архитектуры ИС могут быть, если не основываться на данных?Ответ:По моему мнению, других подходов к проектированию, кроме как на основе данных — нет. Я считаю, что всякое иное проектирование идёт из культа технологий. Мы не проектируем на Django или 1С, мы проектируем на основе данных, которые будет потреблять бизнес. Именно на основе этих данных принимаются решения, которые в итоге приносят деньги и в разы увеличивают доходы.
- Вопрос:О каких данных идёт речь в статье?Ответ:Речь идёт о данных, которые нужны для принятия управленческих решений в точках принятия решений.
Покажу на примере лидогенерации. Из директа инстаграм нашему онлайн-магазину приходят лиды по 10.000 руб и в среднем они покупают на 500 руб. Из некой социальной сети приходят лиды по 500 руб и покупают на 20.000 руб. Куда мы будем увеличивать вложения маркетингового бюджета?
Если мы не работаем в рамках принятия решений, то решение вопроса будет происходить примерно следующим образом: «А давайте добавим денег в директ, потому что мне так хочется, я чувствую, что сейчас из директа попрут заказы!» — скажет директор по маркетингу. Вот и все принятие решений.
Если же мы работаем в рамках точек принятия решений, то, наблюдая текущую картину, уменьшаем вложения в директ, либо модернизируем рекламную компанию. Реализуем принятое решение и отслеживаем результаты наших действий, то есть влияем на систему через контур управления системы и оцениваем результат на основе полученных данных. - Вопрос:Почему такие очевидные вещи (что информационная система — это помощник принятия решений) не воспринимаются нашим управляющим составом?Ответ:В первую очередь это происходит потому, что в нашей стране компетенции корпуса управленцев не дотягивают до уровня общего управленческого опыта, существующего на планете.
Во-вторых, многие управленцы боятся информационных систем, предполагая, что из-за них они потеряют свою уникальность. То есть сейчас менеджер оценивает свою значимость для компании через своё чутьё, на основе которого принимаются решения, а если решения можно будет принимать на основе данных некой системы, то его чутьё уже не будет таким ценным. Менеджер может воспринимать это как потерю индивидуальности, поскольку принятие решений формализуется. Получается, менеджера можно заменить кем угодно, и этот кто-то сможет принимать те же решения.
Автор
Александр Кварцхава
Директор по управлению IT и корпоративной архитектурой
Менеджер, корпоративный архитектор, архитектор 1С, 10 лет в IT.
Эксперт по конфигурации 1С ERP и смежным решениям.
Прошёл путь от линейного аналитика до корпоративного архитектора и IT директора
Эксперт по конфигурации 1С ERP и смежным решениям.
Прошёл путь от линейного аналитика до корпоративного архитектора и IT директора