От ИТ-интегратора до Бизнес-партнера: оптимизация процессов ИТ компании

Бизнес-задача

1. При запуске новых проектов с клиентами компания не всегда четко видела бизнес-цели: клиенты говорили “Хотим внедрить PIM-систему”. Но что такое PIM-система, зачем она нужна и как в итоге понять, что PIM-система работает и можно подписать акты? Выяснять ответы на эти вопросы опасно и дорого, если уже подписан договор. В итоге проекты затягивались, рождались системы «для галочки», что иногда оборачивалось упущенной прибылью, уходом клиентов и ударом по репутации.
2. Разработчики не погружались в бизнес-контекст: очень сложно понять мир клиента, все новые термины, системы, последовательности задач. Такая высокая когнитивная нагрузка вынуждала разработчиков защищать свой разум: “Дайте нам аналитиков, пусть они всё разжуют, а мы будем делать задачи из Jira”. Из-за чего снижались вовлеченность и мотивация команды. А между тем в исследованиях Google’s Project Aristotle отмечено, что разработчик, который понимает контекст проекта, работает в 106 раз эффективнее!
   Понимание контекста работниками интеллектуального труда - это ключевая вещь для ИТ-бизнеса и идеальное место приложения усилий.
3. Также в крупных компаниях, клиентах KT.Team, без единого «понятного всем» фреймворка, сотрудники теряют из виду, кто и за что отвечает, что приводит к «возне» и внутренним конфликтам. Чтобы быть успешными, KT.Team должны быть не просто отличными программистами, но и медиаторами, менторами, менеджерами, скрам-мастерами и так далее. 
4. Без процессного подхода бизнесу сложно увидеть узкие места и сконцентрировать ресурсы на ключевых ограничениях. Команда должна выловить, упорядочить и согласовать весь контекст будущего проекта вместе с Заказчиками в удобной форме и в сжатые сроки и при этом оставаться конкурентной по цене.

Видео на VK

Выбор решения и знакомство с Stormbpmn

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

Это понимание стало ключевой развилкой будущего формата работы KT.Team: множить количество аналитиков разных мастей (как часто принято в ИТ-компаниях с невероятной маржой) ЛИБО дать возможность быстро описывать и понимать контекст будущих проектов одинаково с Клиентами.

Из разных вариантов реализации проектов по оптимизации процессов (графики, wireframe, толстые ТЗ, стрелочки-кружочки) стало понятно, что для положительного исхода событий, необходимо использовать правильную методологию описания контекста, в основе которой лежит BPMN.

Здесь понадобится BPMN с подходящим для компании инструментом, так как BPMN - это сложная нотация, предназначенная для реальных процессов и актуальных задач. 

• Рассматривались популярные онлайн‑редакторы (draw.io, Lucidchart и др.), но от них отказались из‑за перегруженности и отсутствия методологии.
• Ключевым фактором стала минималистичная палитра элементов, которая «не даёт нарисовать лишнего» и тем самым обучает правильному BPMN. Автоматические проверки качества диаграмм по 45 правилам помогали команде быстрее погрузиться в тонкости нотации и методологии.

  Команда Stormbpmn: "Конечно, мы выстрадали эти 45 правил в течение 10 лет на тысячах моделей :) "

• Важную роль сыграло доверие к экспертизе CEO Stormbpmn: Денис Котов больше 9 лет занимается обучением аналитиков, архитекторов, разработчиков, а также публикацией материалов по правильномуBPMN и повышению эффективности процессов. 

Внедрение Stormbpmn

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

• Обучение команды: Stormbpmn вошёл в программу онбординга сотрудников; отдельных специалистов отправили на курсы BPMN от Дениса, после чего моделирование стало базой для всех проектов.
• Парадигма «BPMN-сначала»: почти каждый новый проект с непонятными целями стартует с процессного моделирования или уточнения целевых метрик, что помогает быстро договориться с заказчиком и зафиксировать измеримый эффект процесса оптимизации.
• Общий язык для бизнеса и разработчиков. Правильный BPMN организует компанию и клиента: и компания, и клиент говорят на одном языке, что повышает скорость и качество выполнения проектов. А от некоторых проектов позволяет отказаться, если Клиент даже с помощью KT.Team не может понять, что ему нужно.

Пример модели из проектов KT.Team

Результаты и влияние внедрения

Рекомендации от Stormbpmn

Если вы хотите завершить проект по автоматизации, роботизации или оптимизации бизнес-процессов, а главное не остаться в убытке, рекомендуем следующее:

• Будьте честными перед самим собой и заказчиком в части сроков исполнения и стоимости проекта. Не пытайтесь заполучить проект снижаясь до минимальных сроков реализации. 90% работ превышают плановые сроки и не учитываю это, вы ещё на старте проекта будете в проигрышном положении.
• Закрепляйте в договорах и проектных документах кому вы будете передавать систему, если такого заказчика нет - не идите в проект.
• Не пропускайте этап обследования. Не понимая бизнес-контекста и цели для чего вы создаете систему или разрабатываете функциональность, вы не сможете угадать пожелания заказчика и принести ему ценность.
• Старайтесь как можно раньше демонстрировать прототипы и показывать MVP. Очень часто заказчик сам не понимает что и как он хочет, а руководствуется своими фантазиями. Чем раньше он увидит или пощупает продукт, тем быстрее вам начнет поступать качественная обратная связь.
• Фиксируйте все договоренности в нескольких вариантах (протоколы, сообщения в чатах или письмах, согласованный контекст в базе знаний). Данная работа считается излишней на старте проекта, но потом становиться единственным “спасительным кругом” при разногласиях с клиентом.