🔥 10 самых интересных публикаций по управлению проектами за 5–19 сентября (II) ++ 😐 Давайте сначала сделаем один завод++ Авторам дали на автоматизацию группу промпредприятий. Логично было идти последовательно - автоматизировать, условно, закупки сначала на одном заводе, потом распространить на остальные. Но выяснилось, что процессы четырех предприятий совпадают всего примерно на 40–60%, и первый завод совершенно не является уменьшенной копией остальных. Получается ловушка с крупной переделкой “готового” решения. Поэтому команда сначала исследовала все четыре предприятия и отделила общее ядро от обязательных различий и местной специфики. И уже после этого начала автоматизацию.

👀 Внедрить нельзя легализовать Как один маленький пункт в ТЗ чуть не подвесил контракт на десятки миллионов. Перед конкурсом туда добавили требование переводить внутренние документы с помощью ИИ (кек). Только документы конфиденциальные, наружу их отправлять нельзя, а доступные для закрытого контура модели требуемое качество не обеспечивали. Один пункт не проходит приемку — не закрывается весь контракт. И еще: цикл закупки и внедрения большой корпоративной системы может занимать два-три года, тогда как возможности ИИ за это время успевают измениться несколько раз.

⚡️ Заменили Jira, Slack, Tilda и Confluence своим кодом ради экономии. Экономии не вышло Компания решила сэкономить на четырех платных системах, написала собственные — и через год посчитала результат. В первый год получилось примерно минус 2 млн руб, а выйти в ноль автор рассчитывает только примерно за три года, если стоимость поддержки не вырастет. Такая вот экономия. Собственную систему нужно не только создать, но и поддерживать, проверять изменения, документировать и держать в голове как еще один свой продукт. Зато вторая цель — возможность быстро менять инструменты под собственный процесс — действительно оказалась полезной. В общем, считать нужно не стоимость создания, а полную цену владения плюс работу, которую команда могла бы в это время делать для клиентов.

✝️ Внутренние стандарты работы аналитиков: какие документы и правила дают эффект, а какие живут только в базе знаний Про любовь написать 40 страниц “правильного регламента”, положить его в базу знаний и потом удивляться, почему же это все продолжают работать по-своему. Подход автора: стандарт полезен, если помогает принять конкретное решение ровно в тот момент, когда это решение нужно принять. Перед передачей задачи разработчику нужно делать короткую проверку прямо рядом с задачей. После встречи с разрабом фиксируем решения, открытые вопросы, ответственных, сроки и обязательное изменение основного документа. Еще у каждого стандарта должен быть владелец, иначе через год в базе лежит никому не нужный док.

🧣 От Excel к диалогу: как мы построили ИИ-помощника Эйру для управления портфелем из 100+ проектов В БКС больше ста проектов, около семидесяти из них активны, и сведения о каждом жили одновременно в плане, системе задач, протоколах, таблицах с рисками и отчетах. На ручную сверку одного проекта у автора однажды ушло около полутора часов. И изменения авторы начали не с ИИ. Сначала два года связывали сами проектные данные — планы, состояния, риски, бюджеты, команды и решения, — и только потом поверх этой основы появился помощник, который ищет противоречия и готовит следующий шаг для человека. За первую неделю он выдал больше 1500 сигналов, но автор специально говорит, что это плохой показатель успеха. Настоящий показатель — сколько рекомендаций человек проверил и превратил в действие. И в целом, если система производит всё больше информации, но от этого не меняются решения и действия, она просто производит более дорогой информационный шум.