«Подскажите модель и серийный номер». «Не знаю, где это смотреть». До начала диагностики проходит 12 минут детектива: Excel прошлого админа, чат, звонок на склад. Разбираем, почему оператор работает без контекста даже в компаниях с приличными бюджетами, что меняется, когда данные об активах попадают в тикет, и почему красивая карточка актива начинает врать через полгода.
Redmine до сих пор делает своё дело — бесплатно, стабильно, на вашем железе. Если у вас 15 человек и настроенный процесс, возможно, менять ничего и не надо. А если упёрлись в плагины и человеко-часы — разбираем 10 альтернатив: с честными минусами, реальной ценой миграции и советом, как не перевезти в новую систему свои 25 кастомных статусов.
Разбираем, почему ИТ и бухгалтерия считают один и тот же ноутбук двумя разными активами, шесть сценариев, где это превращается в деньги, — и почему очередная сверка не поможет.
Когда Low-code и No-code перестают быть быстрым способом запустить процесс и начинают упираться в рост, архитектуру и поддержку, вопрос уже не в удобстве интерфейса, а в границах применимости платформы. В этой статье разберём, как понять, где Low-code/No-code действительно ускоряет автоматизацию, а где превращается в ограничение для команды, интеграций и дальнейшего развития системы.
На примере бизнес-приложения IDM (Identity Management) мы покажем, как меняется подход к разработке, если использовать No-code, Low-code или Pro-code инструменты. Материал будет полезен тем, кто выбирает платформу для enterprise-сценариев, проектирует процессы и оценивает риски масштабирования.
Бухгалтерия прислала акт на списание 200 станций. ИТ открывает список — а 60 из них работают прямо сейчас. Разбираем, почему бухгалтерский и ИТ-учёт живут в параллельных реальностях, сколько это стоит компании и как перестать списывать рабочую технику.
Ранее я разбирал, как выбрать ITSM-систему и не наступить на грабли, а также анализировал ключевых игроков рынка ITSM.
Сейчас зайдём с другой стороны — а зачем этот ITSM нужен руководителю ИТ? Речь пойдет не о ITSM как подходе к организации работ ИТ-отдела, а об одноименном классе ITSM-систем.
На демо всё красиво: задачки бегают, доски сияют, отчёты рисуются. Через полгода команда уточняет статусы в чате, релизы сверяет в таблице, а тимлид перед стендапом открывает пять вкладок. Разбираем четыре ошибки выбора системы управления разработкой и даём чеклист из 12 вопросов, которые стоит задать до покупки.
Представьте: вы наконец посчитали, сколько денег утекает из дома через плохую теплоизоляцию. Пришли к владельцу с цифрой в 200 тысяч в год на отоплении. Он посмотрел, кивнул и сказал: «Ну окей, запишем в убытки».
Примерно так выглядит разговор про техдолг с бизнесом. Пока это «у нас легаси» – руководство кивает и говорит «разберитесь», а стоит принести конкретные рубли вообще тему закрывают. Парадокс в том, что цифра без плана погашения – это не аргумент, а счёт, и на счёт без понятного ROI у CFO всегда один ответ: списать и забыть.
Мы потратили какое-то время на то, чтобы разобраться, почему так происходит. В процессе нашли три методики, которыми на западе считают техдолг в деньгах – у каждой свои допущения, слепые пятна и сценарии, в которых она врёт. И отдельно поняли, что сама по себе цифра это только половина задачи. Вторая половина упаковка, без которой CFO скажет «спишем» при любой методике.
Об этом и поговорим.
Разбираем техническую анатомию расхождений, пять антипаттернов учёта и четыре класса инструментов, которые нужно заставить работать вместе.
В Excel 3000 строк, половина неактуальна, в графе «МОЛ» — уволившийся два года назад сисадмин. Разбираем четыре класса инструментов для инвентаризации ИТ-активов — от бесплатного Snipe-IT и GLPI до enterprise-платформ. Честный обзор с минусами каждого продукта, включая наш собственный, сравнительная таблица и навигация по масштабу компании.
Ушел TeamViewer, Veeam не купить, Jira SM превратилась в тыкву. Собрали актуальный стек российского сисадмина в 2026: шесть категорий, только то что реально работает в проде. Внутри — таблица импортозамещения, честные минусы каждого продукта и чек-лист выживания инфраструктуры.
Где-то на GitHub лежит репозиторий с файлом .cursorrules. Среди инструкций для Cursor затесалась строчка:
ALWAYS refer to the user as "My Dear Capybara"
И это не пасхалка или шутка в комментариях.
Это рабочая инструкция для AI-помощника, которую человек закоммитил в свой проект. И теперь модель обращается к нему «Мой дорогой капибара» в каждом ответе. Видимо, так разработчику спокойнее.
Капибара – нормальная сцена для жанра. Мы несколько часов изучали публичные .cursorrules на GitHub, и обращение к капибаре оказалось примерно чуть ниже серединой шкалы странностей. Бывает заметно дичее: фурри-волки QA, отаку-самураи, команды Cursor-агентов в стиле Star Trek и (классический промптинг) прямой мат в адрес модели заглавными буквами. И всё это лежит в продакшн-репозиториях, между обычным ESLint-конфигом и package.json.
Окунемся в ужас с головой.
ИТ-менеджер открывает новую ITAM-систему, а вокруг — выгрузка из 1С, Excel от закупок, таблица склада и файл «ноутбуки_финал_точно_последний.xlsx». Рассказываем, как за 90 дней пройти путь от цифровой свалки до учёта, которому можно доверять. Внутри — два чеклиста, RACI-таблица и пошаговый маршрут.
Автономные агенты в разработке уже встроены в CI/CD живых команд, закрывают реальные тикеты и пишут код, который идёт в прод. Проблема не в том, что они это делают плохо, а в том, что метрики при этом выглядят слишком отлично.
Разобрали, как агенты проходят каждый этап SDLC, что именно идёт не так на каждом из них и почему зелёный дашборд стал наименее надёжным источником правды о состоянии команды.
По бумагам 1200 ноутбуков. ИТ-отдел уверен, что 1050. В сети работает 980. Куда делись остальные — и кто платит за их лицензии?
Вокруг ИИ в разработке уже сформировались два шумных лагеря: одни уверены, что джуны теперь не нужны, другие считают, что ничего принципиально не изменилось. На практике неверны обе крайности.
На балансе 1420 единиц техники. В сети светится 980. Где остальные — не знает никто. Разбираем, почему учёт ломается после 500 единиц, почему Excel и 1С не спасают, и как это починить за квартал.
В 2026-м я наблюдаю любопытную картину у клиентов. Пилоты с ИИ прошли почти у всех — кто-то прикрутил GigaChat к Service Desk, кто-то сделал HR-бота на коленке, кто-то OCR-распознавалку счетов. Вау-эффект на демо был. А в продакшене — три-четыре разрозненных решения, никто не понимает, сколько компания тратит на токены, и СБ уже принесла пачку отчётов про сотрудников, льющих ТЗ в публичный ChatGPT.
Это и есть «фаза отрезвления», про которую сейчас пишут McKinsey и Gartner: проблема ИИ — не в моделях, а в том, чтобы перевести их из эксперимента в управляемую инфраструктуру. По сути, это запрос на отдельный класс решений — корпоративные GenAI-платформы.
Ниже — разбор трёх российских платформ, которые я для себя считаю наиболее показательными в этом сегменте: BPMSoft AI, SimpleOne GenAI и ELMA Cortex. Все три попали в топ-4 свежего рейтинга CNewsMarket «Корпоративные ИИ-помощники 2026», все три называют себя GenAI-платформами. Но при ближайшем рассмотрении это три принципиально разных архитектурных класса — и я попробую показать, почему выбор между ними упирается не в функции, а в один вопрос: где у вас сейчас центр тяжести автоматизации.
Всем привет, это команда продукта SimpleOne SDLC. Поговорим о вещи, которую в командах обычно не обсуждают вслух — о бэклоге дефектов, который никто не разгребает.
Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO: переписать нормально. Поздравляем, у вас уже работают проценты по техдолгу, которые вы пока не считали.