Почему бизнес не получает эффект от проектов автоматизации?
Начнем с того, что в любом IT-проекте бизнес выступает в качестве конечного заказчика, а команда IT-специалистов — в качестве исполнителей. И в процессе работы над проектом может произойти следующее:
- Исполнитель на концептуальном уровне не понимает нужд заказчика, а именно — каких целей бизнес хочет достичь с помощью IT-решения. Это самая плохая ситуация, при которой велики риски, что в итоге бизнес станет «несчастливым обладателем» ненужного решения за свои же деньги. Еще встречается вариант, когда бизнес не только получает то, что не отвечает его целям, так еще с завидным упорством пытается его внедрить! А что, «деньги же уплочены»!
- Другая ситуация, менее неприятная, но тоже критичная — цели ясны, с концепцией все понятно, но не сформированы бизнес-требования. IT слышит пожелания бизнеса, но интерпретирует их по-своему. Правда в том, что бизнес зачастую не умеет/не может составить требования так, чтобы разработчикам это было однозначно понятно. Кроме того, есть вещи, которые бизнес в принципе не может сформулировать, так как они носят технический характер. Если подрядчик требует ТЗ и даже не пытается обсудить его, уточнить и согласовать — это должно вас, как минимум, насторожить. Аналогично, если подрядчик даже не пытается зафиксировать требования или формулирует их абстрактно.
- Бывает, что исполнители хитрят: разработчик сходу не может разобраться, как сделать ту или иную функцию и предлагает сделать другую, которую может реализовать, уверяя заказчика, что это единственный способ, пусть и неудобный для пользователей. И снова бизнес получает не то, что нужно.
- Еще нередко с целью экономии или по незнанию создание IT-решения полностью доверяют программистам. Они же проектируют интерфейс системы и воркфлоу — это чревато тем, что в системе будет неудобно и непонятно работать. UX и UI дизайнеры существуют не просто так — не пытайтесь все отдать на откуп разработчикам. В конечном итоге, это сомнительная экономия.
- Когда решение готово, предстоит новый не менее ответственный этап — внедрение. Этот процесс всегда протекает по-разному и зависит от множества нюансов: масштабов и сложности нового IT-решения, его степени влияния на бизнес, готовности и желания команды принять изменения. Бизнес не всегда может их все учесть и выстроить имплементацию должным образом. А это чревато тем, что внедрение затянется надолго, решение будет имплементировано не полностью и вообще растеряет свою ценность.
- Кроме того, уже в процессе эксплуатации могут быть выявлены ошибки работы нового решения — к сожалению, тестирование перед внедрением не застраховывает от того, что в процессе работы что-то не всплывет. Поэтому, если вы обращаетесь к подрядчику за разработкой, прописывайте в договоре, что выполнение обязательств исполнителя перед заказчиком наступает через, например, месяц после внедрения системы или после устранения всех ошибок, выявленных в процессе эксплуатации за этот период. Обращу внимание, что к этому не относятся доработки системы по новым требованиям бизнеса.
Если резюмировать, то проблема неудачных автоматизаций связана в основном со сложностями бизнеса найти общий язык с разработкой и с отсутствием на проекте специалистов, которые понимают процессы и цели бизнеса, а также нужды пользователей. Что остается сказать... Наличие на проекте бизнес-аналитика исключает подобные проблемы. Стоит иметь это в виду, если хотите получить IT-решение, которое решит проблемы и задачи бизнеса, а не добавит новых.
И для наглядного и детального понимания ситуации поделюсь своим кейсом.
Ко мне обратилась клиника, которая входит в сеть. Сложность, с которой они столкнулись, состояла в следующем: их профиль отличался от остальных клиник сети, соответственно, были процессы отличающиеся от других. В целом каждая клиника была централизованно автоматизирована — была общая система, в которой все работали. Но для моих клиентов было важно также поддерживать процессы, которые нельзя было реализовать в общей системе.
Для решения этой проблемы клиника обратилась в компанию — системный интегратор. Они должны были создать кастомизированную систему, которую потом нужно было интегрировать с общей системой сети. IT-решение было разработано и принято — формально оно соответствовало требованиям заказчика. Контракт был закрыт. Вот только внедрить новое IT-решение мой клиент так и не смог. Собственно, с этим они ко мне и пришли. Мне предстояло разобраться, что препятствовало внедрению, почему так сложно перевести сотрудников в новую систему, которая по идее должна была облегчить им жизнь.
Начала я, конечно, с аудита бизнес-процессов, которые новая система должна была автоматизировать. Изучив их, а также смежные процессы, я нашла несколько некритичных возможностей для доработки и перешла к аудиту IT-решения, с которым компания так и не смогла “сдружиться”.
Тогда стало понятно, почему в текущей реализации новая система не прижилась:
- предыдущие подрядчики реализовали систему поддержки функций, но не процессов — в ней можно было выполнить основные задачи (правда, как оказалось, не все), но нельзя было достичь целей процесса,
- UX и UI дизайн системы просто отсутствовал — скорее это был хаос, неудобный и непонятный пользователю,
- в новом IT-решении отсутствовала возможность мониторинга и контроля даже на уровне отчетности — эта опция не была предусмотрена, так что в системе можно было увидеть только набор данных. Этого было недостаточно для принятия управленческих решений на локальном уровне,
- интеграцию с основной системой предыдущие подрядчики так и не сделали — все данные, которое новое IT-решение должно было автоматически получать из основной системы, сотрудники моего заказчика вносили вручную. А еще это нарушало принципы прозрачности и управляемости бизнесом, что сильно напрягало руководство сети.
В итоге решение пришлось переделывать — с учетом вышеперечисленных серьезных замечаний, это заняло несколько месяцев. На этот раз я привлекла свою команду специалистов — дизайнера и разработчиков. Вместе мы добились того, что все бизнес-требования к системе были выполнены и после тестового периода система была запущена в эксплуатацию.
На самом деле, подобных кейсов, когда приходится за кем-то переделывать IT-решение, у меня немало. И тут важно понимать, что к этому приводит, почему формально реализованное решение не работает, как бизнесу избежать таких проблем и не терять зря время и деньги.