Управленческий кейс №1

Оценка ситуации

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

Кейс №1. Эксцесс исполнителя

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

«У нас не так и вообще, это неудобно»

Что было сделано: обсудили данный вопрос на оперативном статусе менеджером заказчика без эскалации за рамки проектной команды. Выяснили, что до Анны была доведена задача – помочь ребятам перенести текущий процесс в 1С. Менеджер взял на себя разрешение вопроса, провел рабочую встречу с Анной и донес обновленную постановку:

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

В итоге: процесс полностью переложили в систему без доработки, трудозатраты сократились, Анна смогла прийти к возможности формировать планы в режиме on-click.

Кейс №2. Объективная необходимость

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

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

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

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

Кейс №3. Попытка выжать максимум

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

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

«Вы там разберитесь на уровне проекта и приходите»

Что было сделано: было принято решение приостановить работы по проекту. Этому помогла грамотная работа РП с нашей стороны – протоколы, письма, документация. 

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

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

Система работает по сей день.