Успешная и НЕ успешная цифровая трансформация. Взгляд изнутри

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

• Бизнес-заказчик в рабочей группе по разработке\внедрению. Сотрудник, которому предстоит работать с внедряемой системой и пользоваться тем функционал, который разрабатывается. Это не ИТ-специалист, а именно тот, кто возьмет систему в работу.

• Представитель производства в рабочей группе по разработке\внедрению. Руководство может решить внедрить что угодно, но если исполнители не будут пользоваться этими системами, деньги потрачены зря. То есть важно создать такие условия внутри компании\подразделения, когда решением лучше пользоваться, чем не пользоваться. Для это важно, чтобы все понимали для чего им решение, что оно даст, как оно повлияет на исполнение каждодневных обязанностей.

• Наличие данных! Без оцифровки бизнес-процессов не получится запустить ни одну современную ИС. Любая платформа, это в первую очередь, набор алгоритмов по работе с данными – процедуры, правила, процессы. Если данных нет, то нужно сначала оцифровать бумажные носители, навести порядок. И только потом приступать к внедрению или доработке ИС.

• Понимание «точки Б». Что именно вы хотите? Как сейчас и как вы хотите, чтобы было? На эти вопросы важно ответить внутри компании. Да, мы можем предоставить лучшие практики и рассказать о кейсах. Да, заказчик может позаимствовать что-то для себя. Если ситуация достаточно типовая, то подойдет и уже внедряемый вариант. Но чтобы понять это, важно ответить на вопросы выше. Глубже заказчика в его бизнесе разбираются только прямые конкуренты или отр1аслевые аналитики. Мы можем выстроить логику процессов, но то, как эти процессы должны протекать именно в вашем бизнесе с учетом всех особенностей и ограничений – знаете только вы.

• Отсутствие серьезных препятствий. О них ниже.

• Мы сами с усами! Попробовать справиться своими силами с проблемой - естественный порыв. Сколько людей ставят себе диагнозы с помощью google и занимаются самолечением, например? Иногда это работает, а иногда нет. И тогда профессионалам приходится не только решать нашу задачу, но и устранять последствия «самопомощи». Речь не о том, что ИТ-отдел компании, собранный из классных специалистов, не годится для проведения цифровизации. Бывает ведь так, что решение принято за них, а чаще внутренние заказчики не могут донести до ИТ-специалистов свои потребности. Наш совет – начать с качественного аудита и только после него принимать решение, какими силами справляться. Есть ли нужная техэкспертиза в собственной команде? Если нет, то в каком формате ее добирать: аутсорс, аутстафф, time&material? Но и это полдела, есть неочевидная часть айсберга. «Под водой» иногда оказывается нежелание руководства и ИТ-отдела, и бизнес-подразделений в принципе обращаться за помощью. Это часть социальной игры в «успешный успех», когда обращение к другому специалисту приравнивается к признанию беспомощности. Это уже вопрос зрелости бизнес-культуры и менеджмента.

• Русский язык все понимают, разберемся! Руководители подразделений мыслят одними категориями, а технические спецы другими. Редко встречаются «билингвы», которые могут понимать, учитывать и требования руководителе, и инженеров. Профессиональные подрядчики по заказной разработке в этой компетенции прокачены, иначе бы их бизнес превратился в головную боль. Есть звено аналитиков и менеджеров, которые и работаю с трудностями перевода и учитывают интересы всех команд. Они смотрят на бизнес "глазами инженера" и "глазами собственника", учитывая разность потребностей и задач.

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

• Старая самописная система. Это тяжелый случай. Кто-то когда-то - а иногда этот «кто» является действующим сотрудником компании - написал систему, к ней все привыкли, она как-то работает, не развивается, устарела и не отвечает бизнес-требованиям. Но менять её страшно. Старый друг лучше новых двух, да? А если разработчик системы до сих пор работает в компании, то и непонятно, как это сделать. Часто такие люди создают «узкое место», замыкая развитие ИТ-инфраструктуры на себе, тем самым поддерживая собственную ценность и статус в компании, ведь кроме них «самописку» никто не знает.