Как любое явление, вознесенное модой в центр общественного внимания, цифровая трансформация имеет и солнечную, и теневую стороны. Солнечная сторона — это пышные форумы и яркие издания, по которым триумфально шествуют истории цифрового успеха. Это фейерверк фантастических возможностей и достижений, от которых у рядового читателя кружится голова. В тени же, в частных беседах и на узкотематических форумах, проходят негромкие разговоры профессионалов. В том числе — беседы ИТ-директоров компаний, которые либо сами выступали заказчиками на внедрение новейших ИТ-инструментов, либо видели, как это происходит у коллег. Беседы о том, что не принято обсуждать на выставках ИТ-достижений, но с чем специалисты сталкивались и сталкиваются до сих пор.
Я не берусь рассматривать, как это происходит в государственных структурах. Слышал, что очень по-разному. Где-то добиваются фантастических успехов, где-то — вместо цифровой трансформации случается «цифровая деградация». Здесь в каждом случае — своя история, и каждый раз все зависит и от компетентности принимающих решения людей и от баланса личных и деловых интересов. Сконцентрируюсь на том, что мне ближе — на бизнесе. На компаниях, имеющих вполне конкретных владельцев, которые из собственного кармана инвестируют во внедрение новейших информационных технологий, а затем ждут от этого вполне определенных результатов. И далеко не всегда эти результаты получают. Но почему? Здесь, казалось бы, и заинтересованность у инициатора нешуточная, и власти у него предостаточно. То есть, по этим параметрам условия для успешного проекта более благоприятные, чем в госструктурах. Правда, с квалификацией владельца как заказчика бывают досадные недоработки. Из-за них-то и все беды.
Конечно, владелец несет ответственность за проваленный в его компании внедренческий проект или за проект, не принесший ожидаемых бизнес-результатов. Несет реальную ответственность, и не перед кем-то, а перед своим собственным кошельком. Но в каждой сделке участвуют двое, поэтому не меньшую ответственность несет и подрядчик, взявшийся внедрить в бизнес (ключевое здесь слово — бизнес!) те или иные инструменты автоматизации. Для подрядчика каждый провал — это очень некрасивая история и жирное пятно на его профессиональной репутации. Если пятно просто так не выведешь, его лучше прикрыть. Поэтому об успешных проектах знают все. Это — солнечная сторона вопроса, о которой много пишут и много читают, в которую вкладываются немалые рекламные бюджеты. Но никто не вкладывается в освещение неудач. Поэтому о неудачах пишут и читают гораздо меньше. Но что же все-таки говорят и пишут о неудачах представители заказчиков? Даже если оставить в стороне качество самих ИТ-продуктов и качество их поддержки — что можно сказать о неудачах внедрения как такового? Попробуем классифицировать факторы, из которых в тех или иных сочетаниях складываются провальные проекты:
· Интеграторы сработали по принципу «мусор на входе — мусор на выходе», т. е. автоматизировали кривые, нелогичные, неэффективные бизнес-процессы, операционные и управленческие. Раньше глупостями занимались люди, теперь ими занимаются машинные алгоритмы.
· Все автоматизировали замечательно, но ни экономии издержек, ни роста продаж бизнесу это не принесло.
· Интеграторы не довели проект до конца, сославшись на невыполнение обязательств заказчиком. Или, сославшись на ту же причину, настолько затянули сроки или подняли цену, что заказчик сам был вынужден отказаться от проекта.
· Энтузиасты проекта как со стороны исполнителя, так и со стороны заказчика, не справились с сопротивлением персонала. Люди всячески саботировали проект, поскольку не желали менять свои привычки, не желали переучиваться, не желали быть уволенным после передачи функционала машине. Или не желали терять свою неформальную власть, свою экспертную незаменимость.
· Интеграторы не смогли обучить персонал уверенной работе с внедренными ИТ-инструментами. Работать в новой системе персонал так и не начал. И все это висело до тех пор, пока не закончилось тем, что люди вернулись к прежним способам работы. Ну, или еще как-то не менее печально закончилось.
· И, наконец, с чем мне приходилось неоднократно сталкиваться лично и что отчасти относится к самому продукту — враждебные интерфейсы информационных систем. Перегруженные ненужными подробностями экраны, неудобное расположение кнопок и индикаторов, запутанная навигация, режущая глаз графика — все это отталкивает людей настолько, что возникает вопрос: какой же толщины должна быть палка, чтобы с ее помощью заставить кого-то все это выучить и освоить?
Как в вышеперечисленных случаях исполнители объясняются с заказчиками? В 99 случаях из 100 — убедительно обосновывают свою невиновность. Варианты могут быть такие:
· Мы в точности выполнили ту задачу, которую вы перед нами поставили и прописали в договоре. Задача решена, но вы не получили ожидаемого бизнес-результата? Сочувствуем, но мы-то здесь причем? То есть, проблема экономического обоснования проекта и его результатов считается проблемой исключительно заказчика, но никак не исполнителя.
· Мы автоматизировали бизнес-процессы, о которых рассказали ваши сотрудники. Они рассказали — мы описали, затем они подтвердили точность наших описаний под роспись, а мы — автоматизировали. Если что-то не так — спрашивайте со своих подчиненных.
· Ваши сотрудники не являлись вовремя на интервью. Ссылаясь на авральные ситуации — пропускали назначенные встречи. Либо, явившись, не могли с первого раза достаточно точно и полно описать функции, выполняемые ими на рабочих местах. Из-за их нерадивости проект не был закончен в запланированный срок. Вы подписали условия договора в части сроков — извольте теперь за это отвечать.
· Вы не смогли обеспечить выполнение своими подчиненными тех требований, выполнять которые, согласно договорным условиям, было необходимо для успешного внедрения. Тем самым вы нарушили условия договора и сами несете за это ответственность.
· Мы провели все необходимые обучающие мероприятия, но ваши сотрудники почему-то плохо усвоили материал, и это — на их совести.
Весь этот сюжет закономерно приводит к вопросу: какой объем ответственности готов нести подрядчик перед заказчиком? За что он готов отвечать, а за что — не готов? Есть ли у подрядчика профессиональный этический кодекс, и если есть, то каковы его максимы?
Тех, кто думает, что он всего лишь инженер и не обязан разбираться ни в психологии, ни в бизнесе, кто готов отвечать только за бесперебойную связь, отменную работу железа и программного обеспечения, условно назову «интеграторами». Тех же, кто готов отвечать за реальное повышение эффективности бизнеса при помощи ИТ-инструментов, вплоть до получения финансовых результатов и конкурентных преимуществ, — назову «консультантами». Названия эти условные и вряд ли помогут сориентироваться в калейдоскопе игроков на рынке предложений. Кто-то может называться интегратором, но при этом быть великолепным консультантом. С кем-то — история с точностью до наоборот. Дело не в словах, а в стоящих за ними сущностях, в том уровне ответственности, которую готов взять на себя исполнитель.
В самом начале
Казалось бы, пережив первую волну цифровой трансформации, бизнесы должны были извлечь уроки и стать более требовательными. Но, оказывается, уроки извлечены не все и не всеми. Многие заказчики по-прежнему не могут грамотно поставить задачу, четко обозначить результат и проконтролировать юридические тонкости договорных условий. А большинство исполнителей — по-прежнему считают себя «товарищами с ограниченной ответственностью».
К чему стремиться обеим сторонам цифрового проекта? По какой планке мерить и себя, и своего контрагента?
Помечтаем о том, как должен действовать Консультант с большой буквы. Как должен вести проект Интегратор по гамбургскому счету. Чего хочется ждать от идеального исполнителя — того, кто пришел в бизнес всерьез и надолго, претендует на лидерство и готов костьми лечь за свою репутацию.
Во-первых, хочется, чтобы он по возможности разобрался в бизнесе заказчика — в особенностях рынка, в сложившейся системе управления и внутренних процессах, в присущих компании способах работы с контрагентами, в привычках людей выполнять те или иные работы. И дал бы свое предпроектное заключение: стоит ли автоматизировать процессы компании «как есть» или прежде нужно привести их в согласие со здравым смыслом? Быть может, все это настолько отстало от «средней температуры по отрасли», что бизнес все равно будет катиться вниз, что с автоматизацией, что без нее.
От идеального интегратора и консультанта хочется, чтобы он был в состоянии оценить компанию заказчика на фоне отрасли, на фоне лучшего опыта отраслевых компаний и даже на фоне лучшего опыта мировых лидеров. И мог бы предложить такие ходы и организационные изменения, после которых пользы от автоматизация будет на порядок больше.
Хочется, чтобы исполнитель продумал возможные экономические эффекты от внедрения, прикинул сроки окупаемости проекта и — нет, не отвечал бы за эти цифры, — но хотя бы мог честно обсуждать их с заказчиком и вместе с ним работать над точностью прогноза.
Хочется, чтобы исполнитель научился понимать уровень готовности инициаторов, руководства, владельцев и персонала компании к тому или иному типу автоматизации и не брался за заведомо провальные проекты. Не делать этого — значит скатываться к сомнительным заработкам за «пуговицы без претензий» и работать против собственной репутации. Понимание бизнеса, управленческая компетентность и HR-консалтинг — необходимые составляющие любого полноценного внедрения.
Ну, а как должен себя вести идеальный заказчик? Прежде всего — учиться, учиться и учиться. Чтобы стать наконец квалифицированным Заказчиком с большой буквы.
Идеальный заказчик понимает, что нужно автоматизировать в первую очередь. Где в компании узкие места, расшив которые можно повысить производительность и доходность бизнеса в целом. Он следит за новинками на рынке ИТ-инструментов, за успехами и неудачами их внедрения.
Идеальный заказчик основательно просканирует рынок интеграторов, репутацию действующих на нем игроков, историю завершенных проектов и отзывы прежних заказчиков. Он оценит квалификацию исполнителя еще до заключения сделки. При согласовании условий — не оставит ему юридических лазеек для ухода от ответственности. А заключив договор — заставит довести дело до конца и выполнить все обязательства.
У квалифицированного заказчика хватит мудрости трезво оценить готовность коллектива к привносимым автоматизацией изменениям, предвосхитить возможное сопротивление и связанные с ним риски. Хватит знания своих людей, чтобы принять осознанное решение: идти с ними в такой серьезный проект или не идти. А если идти — хватит воли бороться с сопротивлением и если на пути встанут люди, считающие себя незаменимыми — хватит мужества заменить их.
Если бы и заказчик, и исполнитель были хотя бы наполовину идеальными — цифровая трансформация или всегда почти всегда была бы обращена к нам только солнечной стороной.
И все же музыку, под которую пляшет рынок, заказывает клиент. Главный драйвер цифровой трансформации бизнеса — квалифицированный и требовательный заказчик. И цифровая трансформация в бизнесе происходит лишь в той мере, в какой она происходит в головах заказчиков.
