Цифровизация: о чём важно не забыть в начале пути
Статьи всегда легче читать от лица рассказчика, поэтому давайте так и сделаем.
Привет, Хабр! Меня зовут Дмитрий Архипов, я руководитель разработки в Сибур Диджитал. В IT 15 лет, занимаюсь цифровизацией почти 6 лет. Расскажу что это такое, какие задачи возникают в ходе цифровизации, какие бывают стратегии и способы реализации этих стратегий, а также какие проблемы из этого вытекают.
Хочу поделиться опытом с руководителями и менеджерами, которые запускают цифровизацию и внедряют новые продукты. Также будет интересно узнать о потенциальных проблемах разработчикам производственных компаний, где запущена цифровизация. Все трудности — временные. Они очень быстро фиксятся или могут не возникнуть вообще. Но самое важное, что, так или иначе, они будут исправлены, а вы получите опыт решения сложных задач.
Что такое цифровизация?
Цифровизация — это появление новых возможностей для бизнеса за счёт применения современных технологий. Более формальным языком определение звучит как: цифровизация — это процесс внедрения в компании цифровых технологий, сопровождаемый оптимизацией процессов, и внедрением системы управления проектами.
Когда компания проводит цифровизацию, преследуется главная цель — повышение своих финансовых показателей. Например, такого показателя, как EBITDA. Рост EBITDA или других показателей достигается за счёт сокращения затрат, повышения уровня эффективности, гибкости и оперативности принятия решений. Важно чтобы эти решения опирались на реальные данные, а не созданы эмпирическим путём.
Ключевые стратегии цифровизации
Есть три ключевые стратегии цифровизации:
Привлечь экспертизу партнёров;
Привлечь вендоров для цифровизации какого-то процесса и использовать вендорское решение;
Создать или сформировать внутреннюю команду, которая будет выполнять цифровизацию того или иного процесса.
У каждого из этих пунктов есть свои плюсы и минусы. Например, экспертиза партнеров включает широкий кругозор, успешные кейсы в похожих компаниях, с похожими процессами и готовую команду.
Но минус в том, что это внешняя компания. Она не создаст вам свою экспертизу, или экспертиза будет создаваться долго. Плюс внешняя компания не всегда имеет доступ ко всем данным, которые есть у вас, а без доступа продукт может быть недостаточно гибкий и точный.
Вендорское решение может привести к вендор-локу. Но опять же это, как правило, готовое решение, возможно, содержащее лучшие практики рынка.
Внутренняя команда знает весь контекст и это ключевой плюс. Она имеет доступ ко всем данным, понимает, что было 5 лет назад, кто принимал решение и по каким причинам сейчас работает именно так. Но эту команду надо создать. Это ключевой минус, потому что нужно искать у себя людей с уникальными компетенциями и вопрос: как это делать?
Как правило, все компании выбирают гибридный формат, то есть берут сразу все три решения или какие-то из них попарно. Но сегодня я разберу кейсы, которые подразумевают, что вы выбрали вариант, когда у вас есть внутренняя команда.
В начале пути
У нас есть цель — трансформация компании, рост показателей. Мы выбрали стратегию, что у нас есть собственная команда, мы опираемся на её экспертизу. А какое средство реализации стратегии мы будем применять? Все ли инструменты, которые у нас есть, эффективные? Позволят ли они собственной команде, которую мы будем создавать двигаться эффективно и быстро? Будут ли какие-то препятствия? Когда получим эффект?
Когда мы запускаем цифровую трансформацию, у руководства компании ожидания такие: в первом квартале запустили, во втором квартале посмотрим, какие первые эффекты. Но если не во втором квартале, то в третьем уж точно. Но не всегда эти ожидания могут оправдаться по разным причинам.
Команда и инструменты
Как понять, какие причины нас могут застопорить, и какие инструменты и средства нужны команде для реализации намеченных целей и стратегий? Если мы решили, что команда создает оптимизированный процесс, применяет современные технологии, значит, она делает цифровой продукт. Он может быть разным. Например, найденное на рынке готовое решение. Оно внедряется с партнёрами, как-то дорабатывается. Но если у вас какой-то уникальный процесс готовое решение не подойдёт.
На одном из докладов конференции Byte & Oil Conf была показана карта процессов. Там просто куча уникальных процессов для одной или двух компаний. Например, бурение. Получается так, что нам нужно создать цифровой продукт под уникальный процесс, которого больше нет нигде. И, скорее всего, готового решения на рынке просто нет.
Новый цифровой продукт — это продукт, который нужно разработать. И вот внезапно с уровня helicopter view мы спускаемся до чётких и конкретных вещей. У вас появилась команда разработки — конкретные люди, все разные со своими компетенциями, каждый хочет работать по-особенному. Чтобы этим конкретным людям нормально работать и создавать цифровой продукт, обеспечивающий реализацию искомой цели, нужны инженеры. Инженерам нужна техника, где они будут работать. На этой технике должно быть определённое программное обеспечение. Им нужны среды разработки, инструменты CI/CD, инструменты коммуникации. Ещё новые сотрудники могут выражать некоторые потребности, как всё должно выглядеть. Например, пришли люди из IT-компании, из финтехов и говорят, что должно работать так, а у вас сейчас по-другому.
Кейс 1. Наём инженеров
Проблематика
Команды нет, её надо собрать. Компетенции для компании уникальны. Например, не было в компании никогда python-, java-, frontend-разработчиков, никто не занимался machine learning. Надо найти людей и заинтересовать их тем, что у нас интересно, задачи понятные. Разработчики, в свою очередь, не понимают, зачем компании разработка, когда они газ добывают или пластик производят. Многие думают, что в таких компаниях всё на коробках.
Что будет, если не решить?
Всё может прийти к тому, что ребятам будет неинтересно, и вы не сформируете команду быстро. Есть такой средний по рынку показатель, что на создание команды разработки с нуля, может уйти от 3 до 6 месяцев. В первые полгода вы всё ещё не создаете продукт — не внедряете его, не получаете проект, значит, не преследуете искомую цель.
Как решить?
Важно в планировании учитывать время на сбор команды;
Заранее усилить команду подбора, рекрутмента, чтобы ребята понимали, какой профиль должностей они будут искать, как искать и как общаться кандидатами. Разработчики, чаще всего, интроверты. Они очень умные, понимают что делать, делают быстро, но не хотят лишний раз долго разговаривать. Хотят кратко, тезисно: А, В, С — задачу понял, иду делать.
Надо развивать HR-бренд, чтобы люди знали, что у вас идёт трансформация, появились новые задачи и вызовы. Чтобы ребята понимали, что происходит и для чего вы их ищете.
И тут важно использовать помощь партнеров. Если у вас в команде нет джавистов, кто будет проводить интервью, как вы наймете первого джависта? То же самое с первым фронтэндером, аналитиком, архитектором. Можно, конечно, выбросить первую половину стопки резюме, а из второй стопки вытащить счастливчика и решить, что именно он сделает нам счастье. Но лучше попросить партнёров, привлечь к этому IT-компании. Тут важно технологическое партнёрство. И они помогут сформировать первую команду, которая уже дальше по своему образу и подобию будет формировать команду следующего продукта и так далее. Так вы решите первый кейс.
Кейс 2. Техника для инженеров
Проблематика
Инженер в свой первый день работы оформляет кучу документов, подписывает трудовой договор, у него снимают ксерокопии. Дальше ему выдают технику. Обычно это офисная техника для офисных сотрудников, которые работают каждый день в почте, в Excel, в Word или в их аналогах, в каких-то офисных пакетах. И, скорее всего, это ноутбуки или небольшие компьютеры с маленькими экранами. У них мало оперативной памяти, слабый процессор. Они очень энергоэффективны, могут весь день работать без подзарядки, их можно легко переносить. Но это вообще не то что нужно разработчику, потому что задачи разработки требуют производительные компьютеры, сопровождение администратора, мощные процессоры I7 или их аналоги. На machine learning надо много памяти, по умолчанию, 32 гигабайта. Можно посмотреть разные исследования, посчитать какое железо нужно для выполнения задачи и сколько его нужно купить.
Что будет, если не решать
Если выдать инженерам стандартные ПК, то они не смогут решать задачи;
Если инженер не сможет решать свои задачи — он уходит.
Решение
Желательно закупить заранее технику подходящей конфигурации, то есть запланировать.
Ещё один важный момент, что некоторые разработчики не могут работать без компьютера с яблоком. Это не реклама. Просто если вы делаете мобильное приложение под iOS, вы не соберёте его без специфичного железа, не сделаете продукт и не закроете искомую цель. Можно возразить, что всё это можно эмулировать, заменить. Но если посмотреть, кто так делает, то на рынке это 1% компаний. Это не просто так, эмуляторы часто лагают и не работают. В конечном итоге команда просто будет мучиться вместо того, чтобы приносить пользу.
Если разработчик не сможет решать свои задачи, то он уйдёт, а вы опять вернётесь к первому кейсу, будете собирать команду, опять потеряете время. Если этот момент упущен, то можно применить временное решение — разрешить ребятам работать на своей технике. У всех разработчиков есть своя техника, крайне редко можно встретить разработчика без неё. Поэтому пока вы закупаете технику, можно временно разрешить ребятам работать на своей. Это решит проблему и позволит вам двигаться дальше.
Кейс 3. Программное обеспечение
Проблематика
Технику купили, выдали, но где писать код? Очевидно, не в блокноте. Может кто-то и будет писать в блокноте, компилировать ГЦ в консоли, и всё будет хорошо. Но таких людей я не встречал уже лет 15, потому что большинство всё-таки разрабатывает в каких-то IDE. Они разные в зависимости от языка, то есть одни пишут в visual studio, другие в IDE.
У продукта всегда есть две версии. Бесплатная коммьюнити версия и профессиональная платная. Чтобы использовать последние версии языков программирования, последние версии фреймворков, все фичи, которые даёт это IDE, надо пользоваться платной версией.
Что будет, если не решать
Важно закупить лицензии на нужное ПО, так вы снимите юридические и репутационные риски из-за использования бесплатных версий. Также в работе инженеров не будет простоев.
Решение
Запланируйте бюджет на закупку персональных инструментов разработки и начинайте закупать. Вы знаете какие люди к вам придут, вы уже определили профиль компетенции при найме. Наём идёт месяц или несколько месяцев. В этот момент можно закупать разные виды софта. Когда человек выйдет, он уже всё получит. Он будет счастлив оттого, что ему дали всё сразу: технику, софт. Пришёл и начал работать. Самое большое, что разработчики не любят, это ждать. В том числе и поэтому нужно мощное железо. Пока всё скомпилится, из оперативной памяти выгрузится один софт, загрузится другой, в это время разработчик может потерять контекст и вообще забыть, что делал. Не давайте людям ждать, потому что любые простои и ожидания — это деньги вашей компании.
Кейс 4. Среды и инструменты разработки
Проблематика
Разработка ПО — это процесс, в нём есть инструменты, которые его поддерживают, и артефакты, порождающие этот процесс. В среде разработки есть: система версионирования кода, различные сканеры безопасности, сканеры проверки чистоты кода, репозиторий сборки и прочее. Без этого невозможно вести командную разработку. Даже если у вас пока один разработчик, ему нельзя работать без системы версионирования кода. А если у вас команда и они делают один и тот же продукт или если несколько команд, как им это всё собирать?
Что будет, если не решать?
Если этого не обеспечивать, то у ребят будет неэффективная работа, низкий уровень качества продукта, баги, потеряется много времени. Профессиональные инженеры не готовы работать без профессиональных инструментов.
Решение
Нужно спроектировать, развернуть контур разработки. Это можно делать параллельно с формированием команды, потому что тут важно учесть экспертизу того, как им удобнее. Можно смотреть по рынку у кого какой бенчмарк, и спрашивать ребят как им удобно. Вариантов как это сделать много, и ребятам будет приятно, если они будут в это вовлечены.
Когда вы сделаете среду, надо обеспечить процессы предоставления доступов к этому контуру, чтобы эти системы поддерживались. К информационным системам, не должен иметь доступ кто попало, а ещё кто-то должен его предоставлять. Информационные системы тоже иногда могут падать, как и любой программный продукт. Это надо бэкапить. Когда у вас несколько команд, могут выстраиваться девопс практики. Дальше уже происходит переход в область того, что надо выстраивать девопс практики, возможно формировать платформенную команду. Это большая тема для отдельного доклада.
Кейс 5. Инструменты и коммуникации
Проблематика
Разработка ПО подразумевает коммуникацию как внутри команды так и со смежными командами, с пользователями, необходим инструмент или комбинация. Команда — это 5–6 человек, может быть, 10 человек. Когда команд несколько, то это 20 человек. Они должны общаться между собой в работе. И тут даже не про то, что они разговаривают, как прошли выходные, у кого какая задача. Они работают по определённой методологии, предполагающей ритуалы.
Например, демо проводится с третьей стороной — это заказчик, пользователи. Нужно не только где-то переписываться, но и использовать видеосозвон, шаринг экрана. В идеале, нужен один инструмент, позволяющий делать всё — чатиться, создавать чат-группы, где ребята обсуждают какие-то темы и все видят, что именно обсуждается. Возможность добавлять свои комментарии, созвониться с видео, пошарить экран. Если это не одно решение, то хотя бы комплекс решений.
В реальности был кейс, когда в компании для всего перечисленного был только Скайп. И в Скайпе ребята могли только переписываться и созвониться, просто поговорить. История переписки не сохранялась, нельзя было создать группу. Это компания может решить и просто использовать другой более эффективный инструмент коммуникации.
Что будет, если не решать?
Если это не решить, то снизится эффективность команды. Ребята постоянно теряют контекст, если они не видят, какая была история переписки, какие скриншоты прикладывали. Баг уже не обсудить, так как он не сохранился в истории.
Команда может решить это самостоятельно тем, что она уйдёт в публичный мессенджер. Например, в Телеграм. Этот подход имеет свои риски. Когда мессенджер публичный, есть риск информационной безопасности. Мессенджер кто-то может смотреть или сотрудник может уволиться, и не удалиться из группы.
Ещё важно, что группы в телеге — это свой маленький анклав. Чтобы переписываться с другой командой надо знать их канал. Надо, чтобы тебя туда кто-то добавил. А если ты не знаешь, кто там, получается, что у вас уже не какое-то однородное коммьюнити, а набор разных юнитов, которые вроде как рядом, но на самом деле нет. И вообще никто не знает, что происходит за стенкой. Поэтому в идеале как раз задавать инструмент коммуникации, где это всё происходит более бесшовно.
Решение
Есть опенсорсные, платные, бесплатные инструменты. Вы можете сами выбрать, какой именно использовать. Идеальным решением в качестве подзадачи по Цифровизации запустить отдельную инициативу по выбору и внедрению такого решения. Все в одном информационном пространстве раскатывают решение на весь ландшафт, то есть на всех сотрудников: менеджеров проектов, бухгалтеров, методологов. Эту подзадачу лучше не решать факультативно, а открыть эту инициативу, выбрать решение и сделать это. Сделайте прозрачной эту активность.
Ещё один вариант — использовать публичные инструменты и принять этот риск. Такие компании тоже есть, в том числе в IT. Но это их выбор, это тоже может работать, хотя и не так эффективно.
Кейс 6. Потребности новых сотрудников
Проблематика
Новые сотрудники, которые пришли из других компаний имеют свой опыт, особый взгляд на многие вещи. Они могут жаловаться или быть чем-то недовольными. Например, их не устраивает низкая скорость внутренних процессов или реализация инфраструктурных изменений, получение доступа, обслуживание техники, доступность документации. И ребята жалуются не потому, что хотят, чтобы это работало на 5 минут быстрее. Просто они знают, что в другом месте было возможно получить доступ к любому информационному объекту условно за 1 день. Если у вас это занимает полтора дня, ребята ожидают и простаивают лишнее время. Они не хотят простаивать, а хотят приносить пользу и делать продукт.
Где-то на предыдущем месте инфраструктурные изменения были супер автоматизированы через декларативное управление, а у вас вручную расписывают, что надо делать через какой-то бумажный артефакт. Пусть это даже электронный документ, тем не менее его можно распечатать. Приходится на бумаге прописывать, что ты хочешь поменять. Это занимает уже не день, а два, три или неделю. Ребята видят, что можно сделать по-другому, так делают в других компаниях и это действительно будет лучше.
Что будет если не решать?
Сотрудники чувствуют, что что-то неэффективно, а они могут делать эффективную работу. Растёт текучесть кадров, продукт не создаётся, финансовые эффекты не достигаются.
Решение
Важно поддержать ребят, потому что они жалуются на рутинные процессы, которые в вашей компании происходят каждый день. Это не прихоть, а один из моментов совершенствования.
Обычно, у топ-менеджеров в фокусе ключевой процесс — это продажи, УЦП, управление цепочками поставок. Бизнес-процессы — большие, это макропроцессы. Небольшие рутинные процессы, которые происходят каждый день, оказывают ключевое влияние на вашу компанию и на скорость движения вперёд к искомой цели. Если их ускорить, то эффект из решения будет кумулятивный. Компания просто резко улетит в космос. Те вещи, которые вы раньше закладывали, чтобы решать год или несколько кварталов, в силу оптимизации можно решить за несколько месяцев. То есть за 3–4 месяца вы будете получать тот эффект, который заложили от общей инициативы, не во втором полугодии, а уже сейчас. В конечном итоге высокий финансовый эффект получается от цифровизации, и в целом от того, как работает компания.
Есть ещё важный момент. Если ваши сотрудники работают на удалёнке, это не очень актуально. Но если сотрудники ходят в офис, держат одном месте общий, единый контекст, видят друг друга вживую, работают эффективно, то можно задуматься о таком понятии, как agile-офис. Это пространство, где есть чёткие зоны для коммуникации. Есть зоны для спокойной, вдумчивой работы. Есть стены, где на совещании вы можете маркером нарисовать какую-то архитектуру, схему процесса и вместе её обсудить. Вы не будете тратить время на то, чтобы пересылать друг другу по почте, как-то это сделать. По сути, это такой space, где команда как единый юнит организационно работает и создаёт пользу. Делает это быстро и не теряет время на лишние пересылки, на потерю коммуникации или контекста.
Поэтому, если у вашей команды будет запрос на модернизацию вашего офиса, сделайте это. Потому что, если часть команды сидит в одном отделе, на одном этаже, а часть на другом конце этого этажа или вообще этажом выше — это неэффективно и не способствует быстрому движению команды вперёд.
Чтобы узнать, есть ли у ребят недовольство этим, можно спрашивать их, проводить опросы вовлечённости. На рынке есть куча инструментов по измерению вовлечённости, где ребята могут пожаловаться, указать, что именно не оптимально, и отметить своё отношение к тому, что происходит. Это тоже запуск мониторинга вовлечённости и сбор обратной связи сотрудников. Таким образом, команды начинают работать, как внутренний консалтинг всех процессов, которые есть у вас. Растёт кумулятивный эффект от преобразований.
Итоги
Изначально у нас было три цели:
сократить затраты;
повысить эффективность;
повысить гибкость, оперативность в принятии решений.
Но если решить хотя бы перечисленные проблемы, и подойти к ним по принципу, что это непрерывные улучшения внутренних процессов, то вы получаете:
внутренний аудит процессов через обратную связь сотрудников;
единое коммуникационное пространство;
рост вовлечённости всех сотрудников;
оптимизацию общей скорости найма и всех процессов, от которых зависит вся компания. Потому что сотрудников много, это не только команда разработки.
Краткие выводы из этого всего:
Внутренняя команда — это новые процессы и практики.
Собственная команда — внутренний консалтинг.
Сопутствующие инициативы дают мультипликативный эффект.
