ITAM в этой цепочке не замена визе ИТ-директора, а способ сделать так, чтобы эта виза была основана на данных, а не на обзвоне складов. Когда парк 200 машин - можно и руками проверить. Когда 5 000 по трём городам - без системы виза превращается в подпись вслепую.
Спасибо за комментарий - это, пожалуй, лучшее дополнение к статье, которое можно было написать.
Если у вас TNI + PowerShell + 1С работает шесть лет и закрывает задачи, это уже не «кривовато», это боевая система. Менять её имеет смысл только когда боль от текущего процесса станет больше, чем боль от перехода.
Справедливый вопрос. ITSM 365 действительно построен на базе Naumen, но позиционируется как облачный Service Desk - с фокусом на обработку обращений, а не на управление активами. ITAM-функциональность там ограничена: нет полноценного жизненного цикла актива, нет связки с финансами и закупками, нет инвентаризации в том смысле, который мы разбираем в статье. Это как сравнивать Jira и Jira Service Management - похожие корни, разные задачи.
Именно. И самое неудобное - что правильный вопрос звучит не “агенты хорошо или плохо”, а “что именно мы просим оптимизировать и готовы ли жить с последствиями”.
Большинство команд пока предпочитают не формулировать его вслух
Связка 1С + GLPI + вменяемые люди - рабочая комбинация, спору нет. На 800 компов и 20 серверах это действительно закрывает задачу. Вопрос в том, что происходит при масштабировании: когда подразделений становится не 18, а 50, когда появляются склады в разных городах, когда нужно считать TCO и связывать контракты с конкретными активами. GLPI в этой точке начинает упираться - и «вменяемые сотрудники» начинают тратить всё больше времени на то, что система должна делать сама. Но если у вас 1–2% расхождений — это отличный результат
На практике прирост штата зависит от трёх критических факторов: текущего уровня автоматизации, CSAT-метрик и наличия инструментов. Если ваш Service Desk уже хорошо автоматизирован (чат-боты, самообслуживание и др.), то прирост составит примерно 10-15% - это в основном специалисты по анализу качества, улучшению процессов и сбору обратной связи.
Если же Service Desk работает преимущественно вручную, первым шагом должна быть именно автоматизация, а не найм: она высвобождает 20-30% ресурсов, которые затем переучивают на качество и аналитику.
Не все хотят и должны быть творцами, но нужно дать возможность тем, кто хочет влиять на продукт. Если человеку нравится получать четкое ТЗ и писать качественный код это тоже очень ценно. Проблема начинается, когда всех насильно загоняют в режим "просто делай задачу и не задавай вопросов", даже тех кто мог бы предложить что-то дельное
когда от человека ждут, когда он придет и принесет свой проект в бизнес (в чей-то), причем бесплатно, или просто нагенерит коммерческих идей
мы говорим не о том, что разработчик должен генерить бизнес-идеи за продакта. Просто когда человек видит, что мы городим велосипед или архитектура не тянет, он должен иметь возможность это сказать, а не просто писать код по ТЗ
IMHO, ну неправильно это сравнивать взрослых людей с детьми, там, где требуется мало-мальски серьезное отношение.
Возможно, аналогия не очень удачная :) Суть была в том, что если мерить не то, получишь не тот результат. Мерим количество тасков – люди их дробят. Мерим часы – рисуют в конце месяца
Зависит от типа генерального директора, кмк
Да, тут про технического основателя, который понимает продукт. Если он просто согласовывает скрепки, то без комментариев, сами понимаете :)
Под ценностью мы имеем в виду не только деньги, но и знание. Если команда за месяц проверила идею и выяснила, что она не работает или не нужна – это огромная ценность, и вы не потратили год на развитие провальной фичи
И вот антипример: команда полгода делала что-то, что можно было проверить за две недели, или вообще делала не то, что нужно бизнесу, потому что никто не удосужился спросить
для многих компаний Jira действительно работает хорошо Мы рассказали о тех случаях, когда она не справляется. Если у вас в Jira всё прекрасно, значит, она подходит под ваши задачи, и это здорово
В некоторых ситуация ускорение происходит не только от смены таск-трекера. Часто это результат изменения подхода: переход от проектного мышления к продуктовому, улучшение синхронизации команд, интеграция с ITSM для приоритизации на основе инцидентов. Таск-трекер либо помогает этому, либо мешает
Понимаю ваш скепсис, статью я основывал на собственном опыте. Если у вас другой опыт, буду рад услышать, как вы решаете проблемы с синхронизацией команд
по моему мнению, структура инструмента заставляет создавать лишние слои. Бизнес-отдел работает в своём проекте, команды в своих. Связать их можно, но приходится настраивать иерархию или горизонтальные связи, которые Jira не очень любит.
Мы убрали этот промежуточный слой, бизнес и команды работают с одним бэклогом продукта
Справедливо. Речь скорее не про то, что новичок сам выбирает приоритеты, а что ему нужно понять контекст: какой продукт делаем, зачем, как его задача вписывается в общую картину. В Jira это размазано по проектам и Confluence. В SimpleOne продукт с описанием ценности это отдельная сущность, которую сразу видно
А чем менеджер занимается, который управляет этими командами? Почему нельзя просто завести один эпик и в него кинуть 3 разных задачи?
Можно, но когда эпик живёт в одном проекте, а задачи команд в трёх других, получается 4 проекта, между которыми нужно прыгать. Бизнес не опускается в задачи команд, команды поднимаются в эпик бизнеса. Мы решаем это через единый бэклог продукта, из которого команды берут задачи, это плоская структура вместо иерархии проектов
Это вообще не связано с таск трекером. Не беда, если какая-то инфа лежит на конфлюенсе. Человек умрет что-ли, если в конфлюенс перейдет?
Согласен, что информация может лежать где угодно. Но проблема в том, что когда у вас 20+ проектов и 30 команд, новый человек тратит кучу времени, чтобы понять, где его доска, что за продукт делают, зачем это нужно. Confluence отдельно, Jira отдельно, Miro где-то ещё. Единая точка входа упрощает онбординг
Аналогия понятна, но есть нюанс: Mercedes вы покупаете под свои задачи. А Jira многие используют просто потому что все так делают, хотя она под их задачи не заточена. Если у вас одна команда из 5 человек, Jira отлично работает. Если 30 команд и используется например SAFe, начинаются проблемы, которые мы описали
ITAM в этой цепочке не замена визе ИТ-директора, а способ сделать так, чтобы эта виза была основана на данных, а не на обзвоне складов. Когда парк 200 машин - можно и руками проверить. Когда 5 000 по трём городам - без системы виза превращается в подпись вслепую.
Спасибо за комментарий - это, пожалуй, лучшее дополнение к статье, которое можно было написать.
Если у вас TNI + PowerShell + 1С работает шесть лет и закрывает задачи, это уже не «кривовато», это боевая система. Менять её имеет смысл только когда боль от текущего процесса станет больше, чем боль от перехода.
Удачи с бюджетом и с ТСД. И с тётей Людой…
Справедливый вопрос. ITSM 365 действительно построен на базе Naumen, но позиционируется как облачный Service Desk - с фокусом на обработку обращений, а не на управление активами. ITAM-функциональность там ограничена: нет полноценного жизненного цикла актива, нет связки с финансами и закупками, нет инвентаризации в том смысле, который мы разбираем в статье. Это как сравнивать Jira и Jira Service Management - похожие корни, разные задачи.
Именно. И самое неудобное - что правильный вопрос звучит не “агенты хорошо или плохо”, а “что именно мы просим оптимизировать и готовы ли жить с последствиями”.
Большинство команд пока предпочитают не формулировать его вслух
Связка 1С + GLPI + вменяемые люди - рабочая комбинация, спору нет. На 800 компов и 20 серверах это действительно закрывает задачу. Вопрос в том, что происходит при масштабировании: когда подразделений становится не 18, а 50, когда появляются склады в разных городах, когда нужно считать TCO и связывать контракты с конкретными активами. GLPI в этой точке начинает упираться - и «вменяемые сотрудники» начинают тратить всё больше времени на то, что система должна делать сама. Но если у вас 1–2% расхождений — это отличный результат
Он ещё и стикер «не трогать!» повесил - так что формально процесс есть 😄
На практике прирост штата зависит от трёх критических факторов: текущего уровня автоматизации, CSAT-метрик и наличия инструментов. Если ваш Service Desk уже хорошо автоматизирован (чат-боты, самообслуживание и др.), то прирост составит примерно 10-15% - это в основном специалисты по анализу качества, улучшению процессов и сбору обратной связи.
Если же Service Desk работает преимущественно вручную, первым шагом должна быть именно автоматизация, а не найм: она высвобождает 20-30% ресурсов, которые затем переучивают на качество и аналитику.
Посмотреть функциональные возможности обновления можно здесь: https://rutube.ru/video/daebcfb53a9c579401cbcb58cc489f45/
Не все хотят и должны быть творцами, но нужно дать возможность тем, кто хочет влиять на продукт. Если человеку нравится получать четкое ТЗ и писать качественный код это тоже очень ценно. Проблема начинается, когда всех насильно загоняют в режим "просто делай задачу и не задавай вопросов", даже тех кто мог бы предложить что-то дельное
мы говорим не о том, что разработчик должен генерить бизнес-идеи за продакта. Просто когда человек видит, что мы городим велосипед или архитектура не тянет, он должен иметь возможность это сказать, а не просто писать код по ТЗ
Возможно, аналогия не очень удачная :) Суть была в том, что если мерить не то, получишь не тот результат. Мерим количество тасков – люди их дробят. Мерим часы – рисуют в конце месяца
Да, тут про технического основателя, который понимает продукт. Если он просто согласовывает скрепки, то без комментариев, сами понимаете :)
Под ценностью мы имеем в виду не только деньги, но и знание. Если команда за месяц проверила идею и выяснила, что она не работает или не нужна – это огромная ценность, и вы не потратили год на развитие провальной фичи
И вот антипример: команда полгода делала что-то, что можно было проверить за две недели, или вообще делала не то, что нужно бизнесу, потому что никто не удосужился спросить
для многих компаний Jira действительно работает хорошо
Мы рассказали о тех случаях, когда она не справляется. Если у вас в Jira всё прекрасно, значит, она подходит под ваши задачи, и это здорово
В некоторых ситуация ускорение происходит не только от смены таск-трекера. Часто это результат изменения подхода: переход от проектного мышления к продуктовому, улучшение синхронизации команд, интеграция с ITSM для приоритизации на основе инцидентов. Таск-трекер либо помогает этому, либо мешает
Понимаю ваш скепсис, статью я основывал на собственном опыте. Если у вас другой опыт, буду рад услышать, как вы решаете проблемы с синхронизацией команд
по моему мнению, структура инструмента заставляет создавать лишние слои. Бизнес-отдел работает в своём проекте, команды в своих. Связать их можно, но приходится настраивать иерархию или горизонтальные связи, которые Jira не очень любит.
Мы убрали этот промежуточный слой, бизнес и команды работают с одним бэклогом продукта
Справедливо. Речь скорее не про то, что новичок сам выбирает приоритеты, а что ему нужно понять контекст: какой продукт делаем, зачем, как его задача вписывается в общую картину. В Jira это размазано по проектам и Confluence. В SimpleOne продукт с описанием ценности это отдельная сущность, которую сразу видно
Можно, но когда эпик живёт в одном проекте, а задачи команд в трёх других, получается 4 проекта, между которыми нужно прыгать. Бизнес не опускается в задачи команд, команды поднимаются в эпик бизнеса. Мы решаем это через единый бэклог продукта, из которого команды берут задачи, это плоская структура вместо иерархии проектов
Согласен, что информация может лежать где угодно. Но проблема в том, что когда у вас 20+ проектов и 30 команд, новый человек тратит кучу времени, чтобы понять, где его доска, что за продукт делают, зачем это нужно. Confluence отдельно, Jira отдельно, Miro где-то ещё. Единая точка входа упрощает онбординг
Аналогия понятна, но есть нюанс: Mercedes вы покупаете под свои задачи. А Jira многие используют просто потому что все так делают, хотя она под их задачи не заточена. Если у вас одна команда из 5 человек, Jira отлично работает. Если 30 команд и используется например SAFe, начинаются проблемы, которые мы описали
Спасибо, что маякнули! Всё поправили :)