Компас BI – управляй, мотивируй, преобразуй ИТ!

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

IT-управление состоит из четырех направлений:

• поддержка,

• разработка,

• системное администрирование и связь,

• информационная безопасность.

Возглавляет управление IT-директор.

Основной стек нашего ландшафта – 1С. У нас используется много типовых конфигураций: Документооборот, ERP, УПП, Управление холдингом, Зарплата и управление персоналом, Бухгалтерия. Есть несколько конфигураций, разработанных самостоятельно под специфику направлений деятельности нашей компании с учетом уникальности бизнес-процессов. Также используются системы eTraxis, BPM-софт, Битрикс 24 и другие.

У нас выстроена прозрачная система управления: все бизнес-процессы регламентированы, внедрена система KPI, а эффективность каждого этапа оценивается на основе метрик и обратной связи от пользователей.

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

На третьей линии находится мое подразделение – направление разработки бизнес-приложений, которое берет на себя наиболее трудоемкие задачи по изменениям и поддержке систем. Мы обрабатываем четыре типа запросов:

• технологические операции,

• запросы на изменения,

• инциденты,

• запросы на консультации, которые попадают к нам, если вторая линия не может с ними справиться. Это редкая ситуация, но она бывает.

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

Для сбора информации по этим сервисам мы используем BI-систему, которая получает данные из следующих источников: 1С Битрикс Forms (наша разработка для опроса пользователей), Task Tracker, eTraxis, 1С Документооборот, Консультант Плюс, BPM-софт и частично Excel.

История знакомства с BI

На предыдущем месте работы, куда я пришла руководителем в отдел сопровождения и разработки 1С, мне потребовалось очень быстро организовать работу. Отдел рос очень быстро: увеличивалась численность команды и количество обслуживаемых систем. Мне нужна была точка опоры, чтобы оперативно реагировать на отклонения в процессах. Для этого я описала бизнес-процессы по всем трем линиям, ввела метрики и начала их отслеживать. Это помогало принимать превентивные меры и не только устранять проблемы, но и минимизировать риски.

В какой-то момент мне предложили пройти внутренние курсы по BI. С тех пор в моем арсенале появился такой инструмент, как BI-система. Три истории ее практического применения я сейчас и расскажу.

История первая: проблема работы разработчиков в двух системах

Пять лет назад каждый разработчик в моем подразделении работал в двух системах. Одна система предназначалась для управления запросами и относилась к процессной части работ. Вторая система предназначалась для задач средней и высокой трудоемкости и относилась к проектной части работ.

Мы измеряли такие метрики процессов, как:

1. Скорость решения запросов,

2. Количество запросов,

3. Количество инцидентов,

4. Оценка пользователей,

5. Средняя трудоемкость.

Результаты метрик нас не устраивали, так как мы видели, что:

1. Скорость решения запросов можно улучшить,

2. Подход «одна задача – один разработчик» не позволял декомпозировать задачу на нескольких разработчиков, а бизнесу – быстро получить ценность от автоматизации,

3. Разработчикам приходилось работать в двух системах и самостоятельно отслеживать в них сроковую дисциплину,

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

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

1. Конвейерная разработка и технические груминги позволили передавать компетенции внутри подразделения.

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

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

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

Результаты первой истории: анализ метрик в системе BI

Здесь представлены результаты, собранные за два года. Рассматривалась динамика закрытия запросов по периодам в штуках. Был взят год до перехода и год после перехода. За год после перехода количество обработанных запросов выросло: было 690, стало 945.

Также рассматривалась динамика скорости обработки в днях. По показателям последнего месяца до перехода среднее время от регистрации до закрытия запроса составляло 8,5 дней, при том, что SLA по запросам был равен 10 дням. При работе в двух системах у разработчиков не было приоритета на обработку процессных задач. После перехода на новую систему и установки высокого SLA для процессных задач время обработки запросов сократилось до 3,2 дня.

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

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

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

Итоги первой истории

При увеличении количества запросов на 37% мы добились:

• Ускорения решения запросов на 10%,

• Снижения количества дефектов на два порядка,

• Повышения удовлетворенности клиентов на 2%,

• Снижения средней трудоемкости запроса на 19%.

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

История вторая: выявление проблемы на второй линии поддержки

История вторая началась с анализа модели BI. Я пыталась найти причину того, почему в летний квартал мы начали работать значительно медленнее.

Проблема хорошо видна на изображении. Мы выявили ее на ретроспективе команды разработки. Было видно, что запросы начали обрабатываться медленнее. Динамика скорости обработки поползла вверх. Это происходило одновременно с увеличением количества просрочек и на фоне того, что общее количество запросов стало заметно меньше.

Разработчики посмотрели свою систему и сказали, что работают так же, как и раньше. Начался поиск причины. В модель была выведена информация о дате создания запроса и дате передачи запроса на третью линию. Выяснилось, что вторая линия начала передавать запросы позже. Был подключен ведущий консультант, мы провели совместный разбор ситуации и увидели следующую картину.

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

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

Решение проблемы и новые метрики для второй линии

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

Решения:

1. Перешли на вытягивающую систему обработки запросов на второй линии.

2. Добавили две метрики в модель: время передачи запросов на вторую и третью линии и назначение на ответственного на второй линии.

3. С помощью метрик контролируем процесс.

Следующий график показал улучшение динамики скорости обработки.

После внедрения изменений скорость стала выше, количество просрочек снизилось, и это происходило на фоне роста количества запросов.

История третья: управление очередью задач через комитет

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

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

Данные для комитета

Для работы комитета ежемесячно подготавливаются данные, которые формируются на основе BI-модели. В модель загружается очередь задач из системы eTraxis с учетом приоритетов, установленных топ-менеджерами на канбан-доске. Используется собственная канбан-доска разработки, где каждый топ-менеджер может выстроить приоритет задач по своему блоку ответственности. Комитет видит приоритеты, заданные каждым топ-менеджером.

Также собираются данные из системы документооборота по фактической трудоемкости задач. Анализируется, сколько времени направление разработки потратило на каждый вид деятельности. Отображается распределение времени в часах и процентах по видам работ, трудоемкость по каждой задаче, а также динамика создания и закрытия задач. Это позволяет видеть общую динамику и понимать, как направление разработки движется к сокращению длинной очереди задач.

Также мы собираем оценку удовлетворенности заказчиков. Оценка проводится по трем параметрам.

Первый параметр – оценка взаимодействия с IT. Бизнес понимает, что IT не только автоматизирует бизнес, но и активно используется для внесения изменений в сами бизнес-процессы. Задача, которая приходит к нам, как правило, формулируется в свободной форме и далека от идеала. В процессе выявления требований мы не только собираем информацию для автоматизации, но и работаем над реинжинирингом бизнес-процессов совместно с пользователями, ключевыми пользователями и стейкхолдерами. Часто мы участвуем в изменении бизнес-процессов. Реинжиниринг может проводиться совместно с автоматизацией или параллельно с ней. Оценка взаимодействия с IT отражает совместную работу бизнес-заказчика и IT в части реинжиниринга бизнес-процессов.

Второй параметр – оценка эффекта от реализации. Это субъективная оценка заказчика того эффекта, который он получил от внедрения той или иной функциональности.

Третий параметр – удовлетворенность сроками. Около 75% заказчиков довольны тем, насколько оперативно и быстро решаются задачи. Это также субъективная оценка автора задачи, отражающая его мнение о скорости реализации задачи. Оценка не ранжируется, так как пользователь оценивает не только работу IT, но и работу своего руководителя, в том числе то, какой приоритет был установлен для задачи.

Все эти показатели собираются ежемесячно с помощью BI-модели. Вся информация обрабатывается BI и транслируется бизнесу.

Рецепты успешного внедрения BI-системы

Хочу поделиться тем, что я называю рецептами успешного внедрения BI-системы.

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

Для внедрения необходимо проанализировать бизнес-процессы и понять, какие данные уже собираются, а какими данными необходимо дополнить информационные системы, чтобы начать фиксировать их для анализа. Это следует сделать до начала наполнения BI-модели данными или до покупки BI-системы.

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

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

Преимущества BI-систем перед Excel

Также важно сказать о преимуществах BI-систем и причинах их использования.

Большинство графиков, представленных ранее, можно построить в Excel. Однако Excel не способен собрать тот объем информации, который загружается в BI-модель. Он не предназначен для работы с большими объемами данных.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.