Спасибо за статью. Узнаваемая картина: акт "по регламенту", а ИТ смотрит на живых пользователей - и обе стороны по-своему правы. Особенно больно формулировка "никто не ошибся, данные просто не сверялись": решение уже принято в одном контуре, второй узнаёт постфактум.
Хорошо, что вы не останавливаетесь на "нужен ITAM", а раскладываете три категории (работает / мёртвое / неясно) и регламент "статус подтверждён до акта". Без этого даже точная сверка остаётся героизмом конкретного инженера, а не процессом.
Параллель из другого контура - сервисный IT, не железо: там та же геометрия "две логики учёта", только вопросы другие. Бухгалтерия/финансы смотрят на закрытие периода и документ к счёту; поставка - на факт часов и состояние работ в трекере. Акт на списание станций по сроку - близкий аналог ситуации, когда счёт ушёл по календарю, а коммерческий статус по объёму ещё не согласован.
Отсюда же "серая зона": устройство без подтверждённого статуса то же , что и часы/объём без статуса "в деньгах" - в учёте что-то есть, в операционке непонятно, можно ли на это опираться. И та же цена ручной сверки: пока держится на Excel и звонках, масштаб парка/портфеля быстро делает это нежизнеспособным.
Шаг 1 (сверка перед актом) и шаг 2 (статус до документа) кажутся минимально достаточными, даже если интеграция с 1С - потом. Интересно, на вашем опыте: чаще ломается на границе "работает / неясно" или на обратной - "мёртвое, но ещё на балансе"? И сколько циклов списания проходит, прежде чем компания доходит до регламента, а не разовой сверки?
Тезис "интерфейс включили - управление не включили" узнаю полностью. Особенно про Excel, который все ненавидят, но продолжают считать источником правды в споре.
Добавлю только с сервисных IT: иногда "дашборд" вообще не BI, а один еженедельный ритм - кто смотрит на отклонения, кто фиксирует действие, кто возвращается через неделю. Без этого даже аккуратный план-факт остаётся картинкой к разговору, а не инструментом.
Интересно, на каком переходе вашей шкалы чаще всего застревают — 2->3 или 3->4?
Спасибо за статью. Согласен: при регулярных срывах чаще ломается процесс, а не мотивация.
Добавлю слой, который в статье почти не затронут. В услуговых командах (аутсорс, T&M) "срок в трекере" и "коммерческий срок по проекту" - не одно и то же: договорный объём, факт часов, допработы и готовность к счёту часто живут вне канбана. Трекер может показать риск по задаче, а владелец узнает о перерасходе к договору только ближе к акту.
Ранние статусы и прозрачность внутри команды - необходимая база. Но без еженедельной сводки «что это значит для сделки» срыв дедлайна в Jira/ЛидерТаске не всегда превращается в управляемое коммерческое решение до конфликта у счёта. К сожалению, услугах и небольших масштабах команд часто разведены дедлайны по поставке и коммерческий контур.
Добрый день, очень понравилась статья, спасибо. Сильный кейс в том, что MVP сфокусирован не на "CRM ради CRM", а на проектной экономике - маржа и оборот по клиенту до HR, портала и юнит-структуры. Именно здесь у большинства студий T&M самый дорогой разрыв: трекер фиксирует факт, учёт - деньги, а коммерческое решение (scope, CR, готовность к счёту) собирается вручную раз в месяц. Интересно, при переходе к юнит-экономике вы считаете эффективность юнита как P&L или всё ещё якорите решения на марже конкретного клиентского договора?
Добрый день, спасибо за статью. Разделение "задачи vs ИСУП" - в точку. Симптом "задачи закрыты, проект проблемный" у нас чаще звучит как "в Jira ок, по сделке маржа уходит". Полная ИСУП это закрывает, но многим командам раньше нужна не замена Jira, а скорее недельный ритм (базовый уровень -> сжигание -> изменение -> готовность к выставлению счетов). Иначе даже хорошая ИСУП даёт красивый план-факт по срокам, а владелец по-прежнему узнаёт экономику в конце месяца.
Больше всего откликнулась мысль, что проблемы идут не по одной, а «пакетом»: не хватает людей, ИИ внедряют рывками, бюджеты режут, а результат требуют уже в этом квартале.
Из-за этого, как по мне, компании чаще всего экономят не там, где нужно: на качестве данных, нормальном управлении изменениями и планах восстановления. А потом удивляются, почему пилоты по ИИ не выходят в рабочий контур.
По опыту, если нет порядка в данных и ответственности за изменения, остальные инициативы начинают буксовать — хоть по ИБ, хоть по инфраструктуре, хоть по ROI.
Интересно, как вы это видите вживую: у крупных компаний дата-офисы уже реально влияют на решения или пока в основном «на бумаге»?
Спасибо за статью. Узнаваемая картина: акт "по регламенту", а ИТ смотрит на живых пользователей - и обе стороны по-своему правы. Особенно больно формулировка "никто не ошибся, данные просто не сверялись": решение уже принято в одном контуре, второй узнаёт постфактум.
Хорошо, что вы не останавливаетесь на "нужен ITAM", а раскладываете три категории (работает / мёртвое / неясно) и регламент "статус подтверждён до акта". Без этого даже точная сверка остаётся героизмом конкретного инженера, а не процессом.
Параллель из другого контура - сервисный IT, не железо: там та же геометрия "две логики учёта", только вопросы другие. Бухгалтерия/финансы смотрят на закрытие периода и документ к счёту; поставка - на факт часов и состояние работ в трекере. Акт на списание станций по сроку - близкий аналог ситуации, когда счёт ушёл по календарю, а коммерческий статус по объёму ещё не согласован.
Отсюда же "серая зона": устройство без подтверждённого статуса то же , что и часы/объём без статуса "в деньгах" - в учёте что-то есть, в операционке непонятно, можно ли на это опираться. И та же цена ручной сверки: пока держится на Excel и звонках, масштаб парка/портфеля быстро делает это нежизнеспособным.
Шаг 1 (сверка перед актом) и шаг 2 (статус до документа) кажутся минимально достаточными, даже если интеграция с 1С - потом. Интересно, на вашем опыте: чаще ломается на границе "работает / неясно" или на обратной - "мёртвое, но ещё на балансе"? И сколько циклов списания проходит, прежде чем компания доходит до регламента, а не разовой сверки?
Тезис "интерфейс включили - управление не включили" узнаю полностью. Особенно про Excel, который все ненавидят, но продолжают считать источником правды в споре.
Добавлю только с сервисных IT: иногда "дашборд" вообще не BI, а один еженедельный ритм - кто смотрит на отклонения, кто фиксирует действие, кто возвращается через неделю. Без этого даже аккуратный план-факт остаётся картинкой к разговору, а не инструментом.
Интересно, на каком переходе вашей шкалы чаще всего застревают — 2->3 или 3->4?
Спасибо за статью. Согласен: при регулярных срывах чаще ломается процесс, а не мотивация.
Добавлю слой, который в статье почти не затронут. В услуговых командах (аутсорс, T&M) "срок в трекере" и "коммерческий срок по проекту" - не одно и то же: договорный объём, факт часов, допработы и готовность к счёту часто живут вне канбана. Трекер может показать риск по задаче, а владелец узнает о перерасходе к договору только ближе к акту.
Ранние статусы и прозрачность внутри команды - необходимая база. Но без еженедельной сводки «что это значит для сделки» срыв дедлайна в Jira/ЛидерТаске не всегда превращается в управляемое коммерческое решение до конфликта у счёта. К сожалению, услугах и небольших масштабах команд часто разведены дедлайны по поставке и коммерческий контур.
Добрый день, очень понравилась статья, спасибо. Сильный кейс в том, что MVP сфокусирован не на "CRM ради CRM", а на проектной экономике - маржа и оборот по клиенту до HR, портала и юнит-структуры. Именно здесь у большинства студий T&M самый дорогой разрыв: трекер фиксирует факт, учёт - деньги, а коммерческое решение (scope, CR, готовность к счёту) собирается вручную раз в месяц.
Интересно, при переходе к юнит-экономике вы считаете эффективность юнита как P&L или всё ещё якорите решения на марже конкретного клиентского договора?
Добрый день, спасибо за статью. Разделение "задачи vs ИСУП" - в точку. Симптом "задачи закрыты, проект проблемный" у нас чаще звучит как "в Jira ок, по сделке маржа уходит". Полная ИСУП это закрывает, но многим командам раньше нужна не замена Jira, а скорее недельный ритм (базовый уровень -> сжигание -> изменение -> готовность к выставлению счетов). Иначе даже хорошая ИСУП даёт красивый план-факт по срокам, а владелец по-прежнему узнаёт экономику в конце месяца.
Спасибо за материал, прочитал с интересом.
Больше всего откликнулась мысль, что проблемы идут не по одной, а «пакетом»: не хватает людей, ИИ внедряют рывками, бюджеты режут, а результат требуют уже в этом квартале.
Из-за этого, как по мне, компании чаще всего экономят не там, где нужно: на качестве данных, нормальном управлении изменениями и планах восстановления. А потом удивляются, почему пилоты по ИИ не выходят в рабочий контур.
По опыту, если нет порядка в данных и ответственности за изменения, остальные инициативы начинают буксовать — хоть по ИБ, хоть по инфраструктуре, хоть по ROI.
Интересно, как вы это видите вживую: у крупных компаний дата-офисы уже реально влияют на решения или пока в основном «на бумаге»?