Прибыльный проект гораздо труднее закрыть, чем убыточный. У него есть заказчики, защитники внутри команды и самый убедительный аргумент: он приносит деньги. Именно поэтому я бы не ограничивался вопросом, есть ли у него прибыль. Мне важно, чего компания не делает, пока продолжает этот проект. Это не история о том, как я уже закрыл конкретное направление. Это принцип выбора, который я готов защищать: положительный результат сам по себе ещё не даёт проекту бессрочного права на лучшие ресурсы компании...
miroshnikov.dv
Клиент не обязан оплачивать вашу заботу
«Мы даём больше, чем конкуренты. А они всё равно выбирают дешевле». В этой претензии бизнеса к покупателю мне не нравится это «всё равно». Будто клиент уже обязан был оценить наши старания, а теперь ведёт себя неправильно. Возможно, мы действительно плохо объяснили ценность. Но есть менее приятный вариант: мы создали дорогую заботу, которая этому клиенту не нужна. Допустим, поставщик оборудования включает в предложение подробное обучение, быструю техническую поддержку и помощь с запуском. Это условный пример, не история конкретного клиента...
Кто виноват, когда сотрудник выполнил KPI, а компания проиграла?
Я бы не начинал такой разбор с лишения сотрудника премии. Сначала я бы положил на стол правила, по которым мы эту премию обещали. Для собственника это неприятная последовательность. Хочется спросить: «Ты же видел, к чему всё идёт. Почему не остановился?» В ответ можно услышать не менее справедливое: «А за что вы меня оценивали весь год?» Здесь и начинается спор, который нельзя закончить фразой «надо думать о бизнесе». Возьмём условный пример. Руководитель закупок добился более низкой цены. По своему показателю он молодец...
Цифровой сотрудник без роли: кто ставит задачу, проверяет и останавливает действие
Представьте явно составную сцену. Компания подключила программного агента к повторяемому рабочему маршруту. Он получает входящие данные, выполняет несколько последовательных шагов, готовит результат и меняет состояние записи в системе. На обычном входе всё выглядит убедительно. Но затем появляется неоднозначный случай. В исходных данных есть противоречие, а инструкция описывает только стандартный путь. Агент выбирает допустимое с технической точки зрения действие и продолжает цепочку. После этого выясняется, что команда по-разному понимала его роль...
Почему дашборд не создаёт прозрачность, если у показателя нет происхождения
Представьте составную управленческую сцену. На экране собственника открыт аккуратный дашборд. Критичный показатель выделен, а его определение согласовано командой. Значение отклоняется от привычной картины, и собственник задаёт несколько простых вопросов. Из каких первичных записей сложилась эта цифра? Когда данные обновились? Какие фильтры и преобразования применялись? Можно ли повторить расчёт? Автор панели открывает выгрузку, ищет прежнюю таблицу и уточняет у коллеги версию правила. Сам показатель виден всем, а его происхождение доступно только через человека, который помнит путь сборки...
