Внутренние системы компании — ключевой инструмент для эффективной работы сотрудников и стабильного развития бизнеса. Но управлять этими системами сложно, особенно когда речь идет принятии стратегических решений и согласовании со множеством спонсоров и заинтересованных лиц. Меня зовут Александр, я руковожу группой внутренних проектов в Kokoc Group и сегодня расскажу про основные вызовы и решения на базе нашего опыта в управлении проектами.

В Kokoc Group, как и во многих других компаниях, возникала проблема с тем, что задачи ставили все, кому не лень, при этом ответственность за принятие решений или информирование бизнеса никто не хотел нести. Возникал вопрос: кто же является стейкхолдером (владельцем решений — лицом, принимающим решения) и баджет‑холдером (владельцем бюджета — лицом, которое выделяет деньги на проект). Кто действительно может ставить задачи и на кто в какой части должен был нести ответственность по ней?

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

Том Гилб

Kokoc Group по своей структуре уникальна. Мы используем стандартные на рынке системы для повседневных задач, но максимально кастомизируем их под свои нужды, и порой даже слишком. Вот, что сейчас есть в нашем арсенале внутренних проектов:

1С

Нужна для управления финансами и учетом в компании. Это многоуровневая система с документальными согласованиями и интеграциями с внешними и внутренними системами. Она позволяет контролировать финансовые потоки и принимать оперативные решения.

Битрикс24

Используется не только как CRM, но и как многоуровневая система модулей:

• Информационный портал: для опросов, новостей и важной информации.

• Внутренние сервисы: для оформления отсутствий, отпусков, согласования документов и ознакомления с регламентами.

• Система ввода и согласования документов: для юридически значимых документов.

• Система управления знаниями: для обучения сотрудников и планирования их развития.

• Задачник: для контроля выполнения задач.

• CRM модуль: для управления клиентами с дополнительными надстройками.

КИТ

Это кастомизированная ERP‑система, развивающаяся уже 13 лет, которая включает в себя архивную CRM (сейчас мы её не используем), задачник и базу хранения клиентских проектов. Система очень функциональна, но из‑за своей громоздкости и регламентированности иногда затрудняет оперативную работу сотрудников, работающих с клиентами.

Несмотря на связь всех этих систем (процессы могут быть как в одной, так и во всех трёх инструментах), их интеграция оказалась сложной задачей. Нужно было сделать их удобными для бизнеса, при этом учесть законодательные требования и согласовать интересы бизнеса, административной вертикали и ИТ. Главная проблема заключалась в поиске баланса между простотой процессов и соблюдением всех необходимых ограничений а также определении тех, кто эти изменения инициирует, кто будет нести ответственность и в целом участвовать в реализации задачи. Сделать можно всё что угодно, вопрос лишь в ресурсах, пользе и драйверах процесса.

Когда я пришел в Kokoc Group, я быстро осознал одну важную вещь: можно знать все о гибких методологиях, но жить по ним — совсем другое дело. Все мы знаем о преимуществах Agile в управлении разработкой продукта и ведении проектов, но в реальности всё не всегда соответствует методичкам.

Казалось бы, что может быть проще: вводим спринты, формируем бэклог и спокойно работаем. Но проблема вскрылась уже на этапе формирования первого бэклога. Оказалось, что у нас все были инициаторами задач и хотели изменений, но никто не хотел брать на себя ответственность за продукт в целом. Здесь пришло понимание необходимости определить спонсоров продуктов и заинтересованных лиц. Первый шаг в этом направлении мы сделали, используя продукт Bitrix24 и внедрили две методики при формирования продуктового бэклога: MoSCoW и RACI.

Определение спонсоров продуктов оказалось ключевым аспектом для принятия решений по управлению внутренними системами.

Определение спонсоров продуктов

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

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

1С: Финансовый департамент, и спонсор — финансовый директор.

Битрикс24:

• CRM – бизнес-вертикаль, и руководитель вертикали.  

• Сервисные процессы – синергия между руководителями административной и бизнес-вертикали.

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

Основные проблемы в управлении внутренними системами

Управление внутренними системами часто сопровождается рядом проблем, особенно конфликтами интересов между различными сторонами. Например: 

• Различие в приоритетах выполнения задач из бэклога

• Разные понимания бизнес-ценности новой функциональности между финансовым отделом и бизнесом

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

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

Пример одного из конфликтов и его решение 

Конфликт интересов особенно ярко у нас проявился при формировании и согласовании договоров. Бизнес предпочитает вводить только основные данные (например, ИНН и условия сотрудничества), используя автоматическое подтягивание информации для удобства. Финансовый департамент требует детализированного ввода данных для аналитических целей в 1С, включая статьи расходов и информацию о контрагентах. IT менеджеры и команды разработки систем заботятся о надежности данных, структурированности и необходимости регламентов для минимизации сбоев.

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

Для успешного функционирования проекта мы внедрили две методики работы с бэклогом и продуктом, адаптировав их под наши нужды. Эти методики — MoSCoW и RACI — помогли нам повысить эффективность и улучшить организацию работы.

• MoSCoW — методика позволяет определить приоритеты продуктового бэклога, разделяя все активности и задачи на 4 категории (Must (должен), Should (стоит), Could (мог бы), Won»t (не стану)). Это значительно повысило эффективность работы и приоритизировало все  «хотелки». 

• RACI — эта методика помогла нам распределять ответственность между участниками процесса при выполнении и реализации задач, что также улучшило организацию работы.

Применение во внутренних проектах

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

Определение и закрепление ответственности

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

• Ответственный со стороны бизнеса определяет этапы и корректирует бизнес-процессы;

• Аналитик создаёт и публикует инструкции;

• Продакт-менеджер проекта обеспечивает понимание целей и задач разработки среди всех участников.

Применение MoSCoW

Методика MoSCoW разделяет все задачи на четыре категории: Must have (обязательно), Should have (желательно), Could have (возможно), и Won’t have (не будем делать сейчас). Этот подход позволяет нам четко определить, какие задачи требуют немедленного внимания, а какие могут подождать своего часа.

Например, задача по внедрению процесса планирования и согласования отпусков имеет высокий приоритет и относится к категории Must have. Это критично для поддержания четкого и прозрачного рабочего процесса, где каждый сотрудник знает, когда и на сколько он может рассчитывать на отпуск.

С другой стороны, доработки уведомлений для сотрудников в корпоративном мессенджере относятся к категории Should have. Они важны, но не настолько, чтобы отвлекать команду от более насущных задач. Они могут подождать, пока мы не справимся с более критичными аспектами.

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

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

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

Для бизнес и административной вертикали и наших бизнес-юнитов мы назначили ответственного, который координирует и собирает бизнес-требования заинтересованных лиц. Этот ответственный информирует и прорабатывает требования с Group Head. В  структуре в IT-департаменте для внутренних продуктов у нас используется следующая модель:

• Руководитель группы внутренних продуктов (Group Head): отвечает за все внутренние системы и координирует работу менеджеров проектов, и команд разработки, взаимодействует с бизнесом. 

• Менеджер проектов: отвечают за конкретные системы и их развитие, взаимодействуют с командой от бизнеса.

• Команда разработки: занимается технической реализацией и поддержкой систем.

Этот подход позволил централизовать управление требованиями и повысить эффективность взаимодействия между бизнесом и IT.

Пошаговое руководство по выявлению и управлению спонсорами внутренних систем

1. Определить внутренние системы и их функции

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

2. Выявите и/или назначьте спонсора проекта и заинтересованных лиц

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

3. Создайте процесс разработки и согласования задач

Создайте четкий процесс разработки и согласования задач. Определите порядок формирования бэклога, приоритизации задач и распределения ответственности между командами. Внедрите методики MoSCoW и RACI (или те, что подходят вам) для эффективного распределения задач и ответственности.

4. Установите метрики эффективности

Разработайте и внедрите метрики для оценки эффективности работы внутренних систем. Это могут быть показатели производительности, удовлетворенности пользователей и финансовые показатели. Через определенный период (например, 6 месяцев) проведите аудит работоспособности внутренних систем. Оцените, насколько эффективно были реализованы изменения и достигнуты поставленные цели.

Выводы

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

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