Правило 8. Не попадитесь в ловушку «Бабушка кейс»

А как же бабушка?

Продолжать этот список можно бесконечно.

«Бабушка кейс» хорошо известен в телекоме, на нём обломались многие проекты по автоматизации и цифровизации. На мой личный взгляд, это одна из причин, почему телеком проиграл Интернет компаниям и отдал рынок цифровых услуг. Пока в телекоме думали о "бабушке" цифровые компании думали о бизнесе, целевой аудитории и удобстве сервиса.

Когда я только пришёл в телеком в начале двухтысячных годов, эта сфера начала активно развиваться, а с ростом пропускной способности и широким распространением доступа в Интернет начали появляться и цифровые сервисы. Сложно было представить себе современные сервисы, которые бы работали с dial-up на скорости подключения 56 кбит/c, на самом деле не более 32 кбит/c.

С ростом клиентской базы мы стали упираться в потолок и начали делать первые проекты по автоматизации и цифровизации наших клиентских сервисов. Многие проекты, которые мы делали, сталкивались с проблемой так называемой «Бабушка кейс» – это собирательный образ некого человека (в то время была бабушка), который не мог пользоваться современными технологиями. А потому нам нужно было придумывать какие-либо обходные манёвры или включать специальные возможности в наши стандартные кейсы.

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

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

Но мы все-таки двигались вперёд, некоторые проекты реализовывались, прогресс не стоял на месте, и автоматизация постепенно проникала в жизнь.

Со временем накаливалась статистика по использованию сервисов, появлялась обратная связь и статистика начинала работать на нас. Оперируя реальными данными, контраргументировать любителям накинуть на вентиллятор стало проще. И «Бабушка кейс» бабушки начинали выпиливаться из телекома, и постепенно переехали в цифровизацию Госуправления, которая изначально и строилось на базе одной известной телеком компании.

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

Хотя я лично знаю людей, которые работают в ИТ и занимаются развитием, но при этом передают данные о показании счётчиков воды на бумажке, которую нужно отнести в специальный почтовый ящик.

В 2018 году мы даже сделали проект по исследованию бизнес-процесса с помощью технологий process mining. Мы загрузили данные типового процесса подключения и посмотрели, как же выглядит типовой flow. Оказалось, что примено в 80% случаев процесс выглядит так, как нарисовано на бумаге: линейно и друг за другом. А также существует два типовых исключения, позволяющих пропускать шаг бизнес-процесса и возвращаться на шаг назад.

Остальные случаи лежали в пределах 20%. Раскрытие этой части утащило нас в аналитический ад. Некоторые сценарии, составляли меньше 1% и диаграмма бизнес-процесса стала похожа на макаронного монстра.

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

Попытка внедрить в такой процесс adaptive case managment превратило бы проект в каторжный труд на веки вечные.

Если вам кажется, что такие сценарии возможны только для телеком и «Бабушка кейс» вам не грозит - посмотрите на свои требования по ИБ. Порой, если следовать им всем, то IT подразделения будут просто не нужны. Случится это потому, что требования информационной безопасности призывают перевести всё на аналоговые носители, в виду того, что работа в цифровом пространстве небезопасна.

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

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

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

Устранять адептов «Бабушка кейс» просто необходимо, иначе проект легко похоронят под кучей доработок. Это очень не простая задача, и типового способа борьбы не существует. Всё сильно зависит от многих факторов: политический вес, уровень доверия, софт-скиллы и так до бесконечности. Но вот несколько универсальных советов.

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

К сожалению, цифры есть не всегда и не всегда их можно потребовать, во многих новых проектах данные объективно не могут быть предоставлены или запрошены. И тогда всё переходит в поле экспертной оценки, и на этом поле легко проиграть.

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

Сделайте это в духе: «мы готовы выполнить это требование, если это необходимо». Готовы ли вы официально подписаться, что проект не может двигаться дальше без выполнения этого требования?

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

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

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

Когда уже ничего не помогает, оставьте возможность выполнения задачи в ручном режиме. Создайте «Блэкбокс» с полуручным управлением, такие, как правило, всегда можно предусмотреть в архитектуре. Сваливайте туда всё, что не укладывается в типовые сценарии, но не забудьте собирать статистику и делать анализ почему так происходит. Порой в такой зоне можно найти вдохновляющие идеи развития, которые просто выходят за рамки типового понимания. Такие находки могут стать новым стимулом развития.