Ситуация в российской и мировой экономике задает тренд на повышение операционной эффективности любой компании. Сложности с удержанием целевой маржинальности из-за повышения стоимости денег и трансграничных платежей, разрыв привычных мировых цепочек поставок, дефицит квалифицированной рабочей силы и множество других внешних факторов требуют четкого понимания – что происходит с бизнесом и где зоны роста. В таких условиях важно оперативно реагировать, и цифровая модель бизнеса – это основа устойчивости в изменчивой среде, позволяющая управленцам своевременно принимать обоснованные решения.
Что такое подход Data Driven Decision Making
Во многих компаниях, где отсутствует полноценное управление на основании данных, распространены такие подходы как highest paid person’s opinion (HiPPO) – принятие решений, исходя из мнения, интуиции и опыта руководителя, а также на базе общепринятых стандартов отрасли. Но руководитель может ошибиться, в результате компания потеряет деньги, а часть общепринятых практик может не сработать в отдельном бизнесе. В этом случае стоит обратить внимание на подход DDDM – стратегия управления, при которой главным источником информации и главным аргументом при принятии решений выступают данные и их анализ. Data-driven подход дает более объективную картину, снижая роль человеческого фактора.
Впрочем, человеческий фактор не является полностью негативным явлением в принятии решений. Только квалифицированный управленец может сформулировать список контрольных параметров и качественно их трактовать на основании своего опыта, а далее принимать решения, позволяющие компании быть успешной. Роль лидера в управлении необыкновенно значима, а данные – это лишь инструмент, которым люди пользуются в силу своего умения.
Большинство крупных компаний серьезно занимаются работой с цифровыми инструментами и управлением на основании полученных данных, а вот средний и малый бизнес часто проседает в этом вопросе. Справедливо отметить, что собственники МСБ осознают потребность в цифровой трансформации. Однако улучшения носят точечный, реактивный характер и попытки двигаться в этом направлении затухают.
Что тормозит процесс внедрения Data-driven подхода
Главная проблема в том, что загруженные оперативными заботами управленцы не находят времени, чтобы подумать, куда они двигаются, какова их стратегия и цели, какие показатели могут продемонстрировать, что движение идет в нужную сторону. Понимаю, что разговоры о стратегии вызывают изжогу у большинства руководителей, горящих в оперативке, но если не знаешь, куда идешь, то именно там и окажешься. В этом случае путь к успеху будет длиннее. Однако и компании, у которых уже есть видение будущего, базовая стратегия, представление об основных показателях и желание изменить свои процессы с помощью цифровых инструментов, тоже сталкиваются с проблемами при внедрении DDDM. Перечислю их:
- Отсутствие регламентов по работе с цифровыми записями. Нет проработанных бизнес-процессов, из которых понятно – в каком виде и на каком этапе каждого процесса должен остаться цифровой след, кто именно должен его оставить. Плюс недисциплинированность исполнителей, которые оправдываются тем, что они «делом занимались», не понимая, что работа с информационными системами компании – это значимая часть их рабочих задач. Такой подход часто поддерживается руководителями среднего и низшего звена, с которых спрашивают только за оперативные задачи, что еще более усугубляет проблему.
- «Зоопарк» в цифровом инструментарии. Например, системы CRM и управленческого учета, массы файлов Excel и task-менеджер никак не интегрированы между собой, что не позволяет консолидировать данные и собрать единую картину. Причем часто руководители подразделений, из лучших намерений, вводят дублирующие цифровые инструменты, что еще более обедняет общие информационные системы данными.
- Конфликт интересов руководителей подразделений. У каждого из них свое представление о подходах к автоматизации и приоритеты в этом вопросе, а также непонимание, как структура данных участвует в формировании финальных показателей. Речь идет о политике и планах внедрения автоматизации, без которой затраты могут кратно возрасти, потому что по мере развития системы придется переделывать блоки процессов, переучивая людей.
- Сопротивления изменениям. Часто возникает сильная инерция «у нас всегда так делали». Руководитель боится, что внедряемая цифровизация и введение KPI – это «контроль» или «вмешательство», а не поддержка. А линейные сотрудники просто видят в работе с данными дополнительную нагрузку, не видят ценности и удобства.
- Хронический дефицит ресурсов на автоматизацию. Причины связаны как с объективной нехваткой средств, так и субъективной недооценкой важности цифровых данных. Дополнительная проблема – борьба подразделений за ограниченные ресурсы, позволяющих автоматизацию реализовать, что тоже можно отнести к конфликту интересов.
Можно еще назвать некоторое количество факторов, мешающих качественной цифровой трансформации бизнес-процессов, но давайте перейдем к решениям.
От чего зависит успех цифровизации
Без централизованного подразделения со значительным административным ресурсом и без позиционирования его руководителя как «представителя собственника или CEO» цифровизация обречена если не на полный провал, то на вялое прозябание. Это не просто департамент, это центр компетенций с полномочиями, стратегическим видением и операционной ответственностью. В разных компаниях такое подразделение может называться по-разному: Дирекция по качеству или Дирекция по операционной эффективности.
Не нужно путать руководителя выделенной структуры с IT-директором. Более того, IT-подразделение может быть включено в новую дирекцию, потому что техническая реализация цифровой трансформации тоже находится в зоне ответственности новой структуры. Именно тут разрабатываются бизнес-архитектура процессов и стратегия цифровой трансформации на основании целей компании. Здесь утверждаются единые цифровые инструменты, разрабатываются планы их внедрения. Это подразделение является держателем бюджета на цифровизацию и управляет портфелем проектов по реинжинирингу и автоматизации сложных кросс-функциональных проектов. Именно этот руководитель может принять решение в случае конфликта интересов в зоне своей ответственности.
Цифровизация – это про бизнес, а не про IT. Цифровая трансформация не проваливается из-за плохих технологий. А проваливается из-за отсутствия единого центра управления, который бы соединял стратегию, процессы и данные. Если в вашей компании нет такой функции, задайте себе вопрос: «Кто отвечает за то, чтобы цифровизация приносила деньги, а не просто существовала?». Если ответа нет, возможно, пора его создать.
Также читайте:
Это небольшая статья, а не научная работа, где можно осветить все аспекты вопроса. Но все же отвечу на конкретный комментарий.
Размышления о личных качествах и компетенциях сотрудников, которые должны быть включены в рабочие группы, особенно если мы говорим об управлении Портфелем проектов (а трансформация — это и есть портфель проектов по работе с БП, автоматизацией и более мелкими изменениями)- прямая обязанность главы PMO. Часть этой работы, если она нужна, конечно, может входить в функционал HR. Но кто сформулирует запрос в HR -подразделение и кому эти HR-ы предложат кандидатуры? Замечу еще, что при параллельном ведении нескольких кросс-функциональных проектов в компании, все хотят в свои группы одних и тех же коллег, и этим конфликтом интересов при ограниченном ресурсе тоже надо управлять.
Со своей стороны повторюсь- я не настаиваю, чтобы все компании стали использовать предложенный мной инструмент. Даже оливье все хозяйки делают по-разному. Искусство менеджмента и заключается в том, что Вы выбираете подходящие в Вашей ситуации инструменты и достигаете нужных результатов. Моей целью было – показать, что существует еще один.
Конечно.
Если Вы о более формальном отношении к PPM и образовании PMO - понял. Хотя PMO как часть структуры существует далеко не в каждой компании, мягко говоря. И у PMO обычно нет данных о личных качествах сотрудников.
Зависит от масштаба изменений. Но начинается с инициатора или спонсора проекта, если так принято в организации, если есть соответствующий процесс.
Спасибо! Это, действительно, и проблема выбора - в том числе. Изменения неизбежны, но результат не гарантирован.
Такое на уровне проекта обычно заканчивается фатально. Проект без спонсора можно не начинать.
Мой анализ причин проблем не совпадает с авторским, поэтому на те же выделенные Вами как важные вопросы, дам свои ответы:
Потому что не понимают причинно-следственных связей между полученными данными и текущей системой выполнения работ. Данные есть, но из них не понятно, что нужно поменять в деятельности, чтобы получить улучшения. Данные - сами по себе. Процессы - сами по себе.
Потому что для улучшения деятельности предприятия нужно осмысленно преобразовать модель его процессов (т.е. существенно исправить КОНСТРУКЦИЮ предприятия). А текущие цифровые инструменты - это локальное улучшение/автоматизация отдельных текущих процессов (т.е. не проектирование/разработка новой эффективной КОНСТРУКЦИИ предприятия, а локальное улучшение отдельных элементов старой (не эффективной) КОНСТРУКЦИИ). Поэтому, как нет эффекта от автоматизации ХАОСА, так не будет эффекта и от цифровизации ХАОСА. А как из ХАОСА получить годную КОНСТРУКЦИЮ - таких решений у IT-шников нет(((
Единый центр, увы, не означает наличие НУЖНОГО ПО СМЫСЛУ РЕШЕНИЯ. Топы предприятия не понимают что нужно делать, IT-шники и их инструменты эту задачу не решают. Внедрение текущих вариантов ERP, цифровых двойников, интернета вещей, ИИ и т.п. задачу вывода предприятия из ХАОСА увы не решают
По первой части (из двух вопросов) - согласен. Но связываю это с низкой культурой структурно-системного анализа. Ранее я говорил о проблеме элементарного анализа данных: по преимуществу нет компетенций, либо они весьма слабые. В частности, некоторые руководители до сих пор не в курсе, что в Excel есть встроенные надстройки для дата-аналитики, а PowerBI я даже не беру.
Но для исправления конструкции предприятия нужно изначально понимать процессную модель TO-BE, к которой будут пытаться двигаться. С очень большими проблемами в понимании AS-IS такое движение само по себе становится крайне неопределенным. IT-шник может лишь подсказать конкретную нотацию для отрисовки бизнес-процесса, но от руководителя нужно понимание (притом - системное) цепочки создания ценности. Очень часто такого понимания нет, и как следствие - получается просто ускорить хаос.
Единый центр в лице собственника предприятия изначально должен обладать пониманием, что ему нужно получить от своей собственности. Попустительский стиль в этом отношении просто приведет к тому, что топы начнут проталкивать свою повестку. Если собственнику уже ничего не нужно - "жизнь прошла, и все отболело", любые попытки автоматизации станут "инъекцией в протез". Но на практике так редко бывает.
Гораздо чаще есть группа топов, которая "топит" за автоматизацию, цифровизацию и прочие "-изации", четко понимания, что ничего реализовано не будет. В такой постановке они решают частную задачу монетизации должностной ренты. Хороший (качественный) аудит в этих условиях очень быстро позволяет найти не только пофамильно "спонсоров хаоса", но и установить степень материальной ответственности каждого из интересантов.
Наконец, если внезапно оказалось, топы совершенно искренне "не понимают, что нужно делать" - собственнику нужно признать, что он купил дорогой опыт в неудачном HR-проекте. Лекарством будет смена персонала.
Но - опять же - за собственника его работу никто не сделает, и просто "отсидеться бесплатно", переждать кризис не получится. Уровень концептуальных решений, решений о сути и смысле бизнеса всегда остается за тем, кто является конечным его бенефициаром.
"5 Копеек" (по моему опыту) про область применения стандарта/стереотипа про сначала обязательно "AS IS", и тольлко потом "TO BE"
Если для улучшения/развития нужно ЭВОЛЮЦИОНИРОВАТЬ, то ASIS -> TOBE это необходимо. НО
Если для спасения (когда улучшения не помогут) нужно РЕВОЛЮЦИОНИРОВАТЬ, то надо сразу проектировать TOBE (т.к. не важно какой у нас сейчас ASIS раз все надо радикально менять)
И моя т.з.: сейчас подавляющему большинству промпредприятий нужно РЕВОЛЮЦИОНИРОВАТЬ, а они (в лице своих собственников/руководителей/сотрудников) искренне не понимают КУДА и такую задачу не ставят (даже такую гипотезу рассмотреть не хотят).
Если с чистого листа - попутного ветра, но это не революция. Революция предполагает изменение существующего и не происходит на пустом месте.
Для маршрута нужны хотя бы две точки.
На вид - у них нет шансов на успех.
Это - две совершенно разные модели:
1) реинжиниринг - AS-IS -> TO-BE
2) инжиниринг - TO-BE сразу, поскольку нечего "эволюционировать"
Хотя заигрывания с "революционированием" (желательно перманентным) - известная тема в России, понимание "Куда?" все-таки остается необходимым.
Движение ради движения просто сжигает ресурсы, и это нужно лечить. На уровне собственника - его лечит рынок, на уровне руководителя - слабое звено устраняет собственник.
Не просто необходимым. В этом и есть главный вопрос при обсуждении любых изменений. Если мы говорим о содержательной части и обосновании тех или иных решений.
А варианты, сценарии и развилки есть всегда.
Не с "чистого листа", просто не надо тратить силы на определение точного положения текущей точки ASIS, т.к. мы не собираемся продолжать маршрут (эволюционировать). А для того, чтобы составит дорожную карту перехода хватит и текущих обобщенных знаний об ASIS.