Как договорить бизнес и ИТ. Рекомендации переводчика

Менеджмент, IT технологии

ТрифоновАндрей Трифонов,
директор по развитию бизнеса,
TOPS Consulting.


Добрый день, уважаемые коллеги. Воспользовавшись приглашением одного из наших заказчиков, мне недавно удалось проверить некоторые домашние заготовки «в бою». А именно, - практический подход к оценке соответствия технологических инструментов компании ее клиентской стратегии.

Некоторые реверансы и политесы

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

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

Снимаем субъективизм, или подход к диагностике вопроса

Предыдущей публикацией я начал задавать себе и вам вопросы, которые последовательно приближают нас к пониманию реальной ситуации в организации. В основе сложностей оценки бизнес-лидерами, отвечающими за продажи и обслуживание, адекватности ситуации с автоматизацией бизнес-процессов, лежит говоренное-переговоренное расхождение их словарей, жизненного и профессионального опыта со среднестатистическими технологами. Отсутствие возможности выработать свою профессиональную позицию на предмет конкретных технологических решений, обсуждаемых на рабочих встречах, и тем более, более общую архитектуру всего ИТ-зоопарка клиентского контура, толкает бизнес-заказчиков на использование субъективных критериев оценки “надежности” внутренних и внешних контрагентов-технологов.  Неопределенность в свою очередь стимулирует поиск контактов с теми редкими людьми, которые владеют достаточным словарем и коммуникативным инструментарием, чтобы, хотя бы отчасти, перевести технологические вопросы в пространство прямого бизнеса. Снять субъективизм и транспонировать персонифицированные оценки ситуации в более четкие измерения – вот задача экспресс-обследования, которую я пытался решить.

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

В чем суть проблемы, и что не устраивает бизнес

Заказчик, о котором пойдет речь, - довольно крупная финансовая организация, с сетью продаж, различными клиентскими сегментами, стандартным набором продуктов для них и минимальным необходимым набором цифровых сервисов взаимодействия с клиентами. Как у и многих других организаций, начавших свою деятельность в конце 90-х, ИТ-хозяйство заказчика представляет собой довольно хорошо проработанную и отлаженную базовую инфраструктуру, и зоопарк из прикладных ИТ-решений. Прикладное ПО было внедрено в разные годы под вновь появляющиеся требования продуктовых линеек и сервисов. Это разнообразное ПО интегрировано частично унифицировано, а частично напрямую друг с другом. К моменту проведения обследования в организации назрел определенный кризис, вызванный ограниченностью средств на серьезную модернизацию прикладных систем с одной стороны, и понимания бизнес руководства, что клиентская стратегия в ее эволюционном развитии дошла до момента, где требуется серьезная поэтапная трансформация. ИТ-департамент настаивал на замене почти десятка исторических систем на две новых промышленных, однако внутренние спонсоры нашли представленную аргументацию недостаточно убедительной и стали искать внешних экспертов.

Итак, вопрос в существующих технологических ограничениях, их подаче и трактовке всеми участниками процесса. Что явилось причиной мнения, что существующие системы не годятся. Таких факторов четыре:

1) доработки делаются существенно (более 2-х раз) дольше, чем это кажется бизнес-заказчику должно занимать времени,

2) получающиеся функции не совсем такие, какие в идеале им хотелось бы получить,

3) финансовая служба критикует ИТ за нарастающие расходы как всего хозяйства, так и средний чек на доработку,

4) все чаще происходят сбои, на исправление причин которых отвлекается все больше человеко-дней как ИТ, так и ключевых бизнес пользователей. Где объективные и где субъективные причины такого типичного разрыва?

Почему доработки делаются дольше, чем кажется бизнесу они должны занимать?

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

Это правило, написанное кровью, точнее серьезными убытками организаций, прошедших через понимание необходимости такого контроля. В части адекватности процедур защиты проекта, контроля качества – их сложность, очевидно, должна соответствовать степени критичности влияния на бизнес и организационной готовности организации. Эмпирически могу порекомендовать ориентироваться на цифру процентного соотношения времени, затрачиваемого проектной командой на организационную нагрузку (согласования требований, подготовка и защита проекта, статусные встречи, комплексное тестирование, документирование), и времени, непосредственно потраченного на автоматизацию функционала (выработка требований, разработка архитектуры, прототипирование, разработка и конфигурирование, функциональное и пользовательское тестирование, обучение, разворачивание) – оргнагрузка не должна превышать 40-50% длительности всего процесса.

Отсюда легко видеть, что ожидание бизнес-заказчиком модификации, с момента высказанного первого требования новой функциональности до ее получения в боевой системе, почти в 2 раза больше относительно его субъективных ожиданий (сели, поговорили, запрограммировали + сконфигурировали, посмотрели, запустили). Это реалии крупного бизнеса. У заказчика, о котором идет речь, этот показатель превысил 80%. Конечно, помимо приведенного соотношения, на градус непонимания влияет комплекс субъективных факторов и персоналий, и влияет весьма существенно.

Почему на выходе получается не совсем то, и не совсем так, как думал бизнес-заказчик

По опыту, дело не столько в том, что требования неаккуратно или недостаточно подробно зафиксированы. Причина чаще в визуальной сложности формы фиксации требований: слишком много слов и мало примеров, картинок, иллюстраций реализации. Технократический стиль изложения годиться лишь для бизнес-собеседника технократического же типажа, что в большинстве случаев совсем не так. Весьма популярная сейчас методология agile как раз и делает акцент на итерационное получение ожидаемого результата с минимумом неожиданностей в конце процесса. Она все еще не массово используется в крупных организациях по ряду понятных причин: 1) отчасти противоречие с традиционными методами контроля операционных рисков, описанных в предыдущем абзаце, 2) необходимость входить процесс проектирования и реализации модификаций при весьма приблизительном понимании стоимости конечного результата. Столь существенные минусы следует компенсировать комбинированием традиционных методов ведения проектов и agile подхода в части итерационного достижения максимально ожидаемого бизнес пользователями результата как по функционалу, так и по интерфейсу. В обследуемом заказчике использовалась традиционная схема производственного цикла управления изменениями – через объемную, преимущественно текстовую, документацию.

Почему расходы на ИТ становятся непропорциональны бизнес-показателям

Нарастающие расходы на ИТ, непропорциональные росту бизнес показателей (число продуктов в линейке, число клиентов, число сотрудников, доходность бизнеса) – прямое следствие увеличивающихся функций организационного контроля и непропорционального усложнения ИТ-хозяйства. Усложнение ИТ-ландшафта, в свою очередь, вызвано ростом числа бизнес-приложений и геометрическим ростом количества связей между ними. Концепция enterprise service bus – универсальной шины, связывающей все ИТ-системы, так же просто, как вилка и розетка, к сожалению, на практике вылилась в то, что мечта осталась реализованной лишь частично, поскольку сложность полной унификации интерфейсов на определенном этапе развития ИТ инфраструктуры начинает превышать совокупную сложность прямых обменов данными между системами. В заказчике, о котором идет речь, универсальная шина обеспечивает интерфейсы лишь с ключевой учетной системой и клиентской базой. Остальные взаимодействия строятся преимущественно на прямых линках.

Увеличение количества и разрушительности сбоев – прямое следствие увеличившейся сложности и связанности ИТ-систем, и, к сожалению, оно не может быть полностью компенсировано жесткостью организационных контролей. В обследованной организации различные компоненты ключевых бизнес систем сбоили несколько раз за календарный год, и простой каждый раз составлял более часа.

Самое интересное. Диагноз и рекомендации.

Итак, бизнес организации и его технологическое обеспечение эволюционировали с конца 90-х, пережив несколько существенных апгрейдов, в связи с выводом на рынок новых линеек продуктов. Уровень контрольных процедур рос в целом пропорционально зрелости бизнеса, однако на этапе расширения сотрудничества с иностранными партнерами сделал резкий скачок в сторону контроля операционных рисков. По факту, серьезное усиление контрольных функций не привело к пропорциональному снижению операционных рисков, но сильно замедлило цикл внедрения бизнес изменений. Налаженный диалог бизнес заказчиков и технологов формализуется через объемные технические задания, которые детально прорабатываются и только потом выносятся на комитет по инвестициям, расход ресурсов на проработку при этом вырос многократно. Мотивация бизнес заказчиков и ИТ-технологов при столь существенном замедлении сроков получения желаемого дополнительного функционала сильно упала. Ситуация усугубилась большим количеством отказов инвестиционного комитета в открытии уже проработанных проектов, в связи со снижением доходности бизнеса и, как следствие, уменьшением бюджета на технологическое развитие. Степень недовольства своим ИТ постепенно нарастает, в связи с ростом числа сбоев, увеличением стоимости владения, постоянным замедлением процесса выполнения заказанных функциональных изменений.

Как с этим справляться. Вот несколько действий, направленных на исправление выявленных негативных тенденций, весьма кстати стандартных для любого крупного предприятия в текущей экономической ситуации:

1)      Диалог с бизнес-заказчиками. Технологам следует использовать больше визуальных средств в демонстрации возможных вариантов, одним из наиболее действенных является инструмент аналогий с тем, что есть у других предприятий. Крайне важна персональная совместимость ключевых лиц, ведущих диалог, об очередном функциональном изменении. Понятно, что выбор среди штатных сотрудников ограничен, и они иногда меняются, однако опыт показывает, что шероховатости общения стоят организации многократно больше, чем необходимость выполнять тяжеловесные контрольные процедуры управления изменениями. Ядро change management team по ключевым направлениям бизнеса нужно держать всеми возможными средствами. Недостаточно распространена практика использования аналитиков технологических партнеров, как в качестве дополнительных носителей опыта, так и для сглаживания субъективных проблем общения в команде.

2)      Для достижения желаемого результата следует применять метод итераций и прототипов, который снижает риск получения плохого результата в самом конце проекта, как следствия разной трактовки зафиксированных требований.

3)      При защите проекта следует рассмотреть вариант раздвижения вилки стоимости проекта, за счет снижения объема предварительной проработки и обеспечения большей свободы в итерационном движении к желаемому результату.

4)      Управляющий комитет должен обязательно включать бизнес-руководителя, отвечающего за реализацию защищенных на инвесткомитете экономических расчетов по возвратности инвестиций в проект. Снижение уровня представительства ведет к размыванию фокуса усилий. Обычная для руководителей такого уровня перегрузка рабочего графика может быть скомпенсирована кардинальным уменьшением числа проектов – пусть останутся только самые значимые, но с его участием, и с многократно более высоким шансом выйти на заявленные экономические результаты.

5)      Множественность и вариативность архитектур ИТ-систем карманного уровня следует стратегически уменьшать за счет перехода на промышленные платформы, на которых строятся ключевые бизнес-системы. Переход должен быть поэтапным как в части планирования функциональных релизов, так и в части финансирования этапов. Многие инвестиции в базовые ИТ-компоненты в организациях уже сделаны, как минимум железо и базовая ИТ-инфраструктура в состоянии обслужить большую вычислительную нагрузку за счет виртуализации и эффективного использования имеющихся активов.

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

7)      Во избежание повторного неконтролируемого разрастания сложности ИТ-ландшафта следует создать действующий компетентный Архитектурный комитет из самых зрелых технологов и стратегических партнеров, для последовательной реализации плана трансформации ИТ-архитектуры и выработки правильных технологических решений на каждом шаге.

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

Удачи и до новых встреч.

Андрей Трифонов