Внутренний аудит портфеля приложений перед загруженным кварталом

Почему это быстро превращается в хаос

Обычно рост числа инструментов начинается с вполне разумной хитрости. Команде нужен трекер, форма или небольшой скрипт, и кто-то собирает это за один день. Всё работает, люди начинают на это полагаться, а потом никто уже не останавливается и не спрашивает, к чему это относится и кто должен это поддерживать.

Этот сценарий повторяется команда за командой. Финансы ведут таблицу для прогнозов. Операционный отдел добавляет форму для согласований. Продажи сохраняют скрипт, который очищает выгрузки перед встречами по понедельникам. Каждый инструмент решает реальную задачу, но в итоге компания получает лоскутное одеяло, которое росло без общей карты.

Проблема становится хуже, потому что почти ни в одной компании нет полного единого списка. Какие-то инструменты лежат в общих папках. Какие-то — в личных каталогах. Какие-то запускаются с ноутбука одного сотрудника. Другие прячутся внутри старых автоматизаций, которые по-прежнему каждое утро рассылают письма. Если попросить трёх руководителей назвать полный набор, обычно получится три неполных ответа.

Владение становится тем местом, где маленькие инструменты превращаются в риск. Люди доверяют таблице или скрипту, потому что у него есть

Что включать в обзор

Начинайте шире, чем с официального списка ПО. Чаще всего проблемы создают те инструменты, которые люди сделали, чтобы сэкономить 15 минут, а потом продолжили использовать два года подряд.

Для первого внутреннего аудита портфеля приложений включайте всё, что хранит бизнес-данные, изменяет их, направляет работу дальше или выдаёт цифры, которым люди доверяют. Если команда пользуется чем-то каждую неделю, добавляйте это в список, даже если никто не называет это приложением.

Общие таблицы тоже заслуживают пристального внимания. Одна простая таблица с сырыми данными — это одно. Таблица с формулами, ссылками между листами, импортами, сводными таблицами или макросами уже ближе к небольшой рабочей системе, особенно если её редактируют несколько человек или другой отчёт берёт из неё данные.

Формы тоже входят в обзор. Многие компании используют формы для заявок на закупку, согласования отпусков, приёма запросов от клиентов, регистрации инцидентов или ежемесячных обновлений. Как только форма начинает отправлять письма, создавать задачи, обновлять таблицу или запускать цепочку согласований, даже маленькая ошибка в настройке может остановить работу целой команды.

Есть ещё скрипты. Они часто скрыты на виду, потому что работают тихо в фоне. Если кто-то написал скрипт для очистки CSV-файлов, объединения выгрузок, переименования документов, переноса записей между системами или создания отчёта по расписанию, включайте его в проверку, даже если код трогает только один человек.

Личные базы данных, дашборды и трекеры тоже считаются. Менеджер по продажам может вести личный трекер прогноза. Финансы могут опираться на самодельную базу для проверки бюджета. Операционный отдел может использовать дашборд, который умеет исправить только один аналитик. Если один человек отвечает за логику, а другие полагаются на результат, риск вполне реальный.

Помогает короткая проверка:

• Инструмент меняет или объединяет данные?
• Он запускает письма, согласования или последующую работу?
• Другие люди зависят от его результата?
• Работа замедлится, если владелец уйдёт на неделю?
• Одна команда начала использовать его без централизованного согласования?

Последний пункт важнее, чем многим руководителям кажется. Инструменты, которые команда купила по корпоративной карте, собрала в общей папке или разослала через копирование и вставку, нередко становятся частью ежедневной работы ещё до того, как кто-то успевает их проверить.

Если люди начнут метаться, когда он сломается в последнюю неделю квартала, его место — в обзоре.

Как собрать первую инвентаризацию

Начинайте с реальной рабочей недели, а не с официального списка ПО. Инструменты, которые ломаются под нагрузкой, чаще всего как раз те, которые никто не планировал: таблица, которую менеджер обновляет каждый понедельник, форма, связанная с общей почтой, или скрипт, который умеет запускать только один аналитик.

Попросите каждую команду перечислить все инструменты, которыми она пользуется в обычную неделю. Формулировка должна быть простой: что вы открываете, редактируете, отправляете или запускаете, чтобы делать работу? Продажи, финансы, операционный отдел, поддержка и HR вспомнят разные вещи, и именно это вам и нужно.

Не ограничивайтесь только названными приложениями. Выгружайте списки из конструкторов форм, аккаунтов автоматизаций, панелей администратора SaaS, общих папок и папок со скриптами. Многие компании думают, что используют 20 инструментов, а потом находят 70, когда начинают считать Google Sheets, файлы Excel, базы Airtable, сценарии Zapier, небольшие Python-скрипты и дашборды, собранные одним человеком под один процесс.

Сложите всё в один лист инвентаризации, по одной строке на каждый инструмент. Столбцы держите простыми:

• название инструмента
• владелец или команда
• постоянные пользователи
• назначение простыми словами
• откуда данные берутся и куда уходят

Последний пункт показывает, как работа движется на самом деле. Если данные начинаются в форме, попадают в таблицу, а потом вручную копируются в payroll или выставление счетов, у вас уже есть несколько точек, где ошибка может разойтись дальше. Запишите весь путь, даже если он кажется очевидным.

Некоторые записи будут выглядеть неаккуратно, и это нормально. «Трекер бюджета, у Priya, используется финансами и операционным отделом, берёт данные из форм заказов, заканчивается в файле месячного закрытия» — этого достаточно для первого прохода. Внутренний аудит портфеля приложений ставит охват выше идеального оформления.

Если один и тот же инструмент используют две команды для разных задач, оставьте одну строку и отметьте обе команды. Если никто не может назвать владельца, пометьте это как неизвестное, а не угадывайте. Неизвестный владелец — полезная информация, потому что обычно она указывает на инструмент, который может тихо выйти из строя.

Хорошая первая инвентаризация выглядит просто. Это её сила. Когда квартал становится загруженным, простой список помогает увидеть, что вообще существует, кто от этого зависит и какие инструменты стоит проверить внимательнее, прежде чем они создадут проблемы.

Как сортировать инструменты по риску и использованию

Не начинайте со сложной модели. Для первого внутреннего аудита портфеля приложений грубая, но понятная оценка работает лучше, чем хитрая. Вам нужен быстрый способ понять, какие инструменты могут ударить по бизнесу, если сломаются, и какими люди пользуются каждый день.

Используйте простую оценку

Дайте каждому инструменту две оценки: риск и использование.

• Оцените влияние от 1 до 5 по тому, что произойдёт, если инструмент перестанет работать. 1 — это небольшое неудобство. 5 — это когда останавливаются зарплата, выставление счетов, доставка клиентам или работа в конце месяца.
• Оцените зависимость от 1 до 5 по тому, сколько людей на него опирается. Лист-помощник одного человека — это не то же самое, что форма, которой пользуются три команды.
• Оцените частоту от 1 до 5 по тому, как часто люди запускают его или обновляют. Инструменты, которыми пользуются каждый день, обычно заслуживают больше внимания, чем то, что открывают раз в квартал.
• Добавьте флаг риска, если инструмент работает с деньгами, данными клиентов, данными сотрудников или записями, связанными с соблюдением требований. Этот флаг должен поднимать его выше в списке, даже если им пользуется лишь несколько человек.

Не усложняйте математику. Многие команды считают риск как влияние плюс чувствительность данных, а использование — как зависимость плюс частоту. Вам не нужна идеальная оценка. Вам нужна одинаковая оценка для всех.

Потом разместите каждый инструмент на простой сетке. Инструменты с высоким риском и высоким использованием попадают в правый верхний угол. Их чинят первыми. Они ломаются громко и в самый неподходящий момент. Инструменты с высоким риском и низким использованием тоже важны, особенно если финансы, юристы или безопасность зависят от них перед дедлайном. Инструменты с низким риском и высоким использованием обычно нуждаются в наведении порядка, назначении владельца и запасных шагах. Инструменты с низким риском и низким использованием чаще всего идут в архив или в список на вывод из эксплуатации.

Небольшой пример делает это понятнее. Таблица, в которой отслеживают согласования счетов, может обновляться всего два раза в неделю, но если одна сломанная формула задержит выплаты, риск высокий. Форма для записи на командный обед может получать трафик каждый день, но риск у неё низкий. Сортируйте так, и следующие шаги станут очевиднее.

Что проверять в каждом инструменте

Большинство внутренних инструментов ломаются не потому, что одна формула даёт сбой. Они ломаются потому, что никто не знает, кто может их менять, кто подстрахует владельца и как откатить неудачное изменение.

Начните с доступа. Запишите, кто прямо сейчас может редактировать таблицу, форму, скрипт или базу данных. Используйте реальные имена, а не должности. Вам нужен текущий список редакторов, администраторов и всех, кто может менять логику или данные. Общие логины заслуживают особого подозрения, потому что они скрывают, кто именно что поменял.

Потом проверьте, что будет, если владелец исчезнет на неделю. Отпуска достаточно, чтобы вскрыть слабую схему. Задайте простой вопрос: кто сможет запустить этот инструмент, исправить мелкую проблему и ответить на вопросы пользователей, если основной владелец отсутствует? Если ответ — «только Sam знает, как это сделать», считайте инструмент хрупким.

Восстановление версии важнее, чем ожидают команды. Узнайте, могут ли люди вернуть более раннюю версию без паники. У таблицы может быть история изменений, скрипт может лежать в Git, а маленькая база данных может опираться на резервные копии. Не доверяйте предположениям. Попросите кого-то показать последний тест восстановления или хотя бы подтвердить, когда в последний раз они откатывали изменение.

Ручная работа вокруг инструмента показывает, насколько вероятно, что он сломается под нагрузкой. Многие инструменты по-прежнему зависят от того, что кто-то выгружает CSV, очищает столбцы, копирует значения в другой файл, отправляет сообщение на согласование или запускает скрипт с ноутбука. В спокойную неделю такие шаги выглядят безобидно. В загруженный квартал они превращаются в задержки и ошибки.

Зафиксируйте несколько фактов в инвентаризации:

• текущие редакторы и резервный владелец
• может ли команда восстановить предыдущую версию
• какие ручные шаги происходят до или после работы инструмента
• дата последнего теста полного процесса

Последний пункт часто показывает настоящий риск. Инструмент может открываться каждый день и при этом всё равно ломаться, когда команда запускает весь процесс целиком. Для внутреннего аудита портфеля приложений такая проверка помогает заметить инструменты, которые выглядят стабильными, но трескаются при росте объёма.

Простой пример из финансов и операционной работы

У растущей компании слабое место часто находится в месте, которое выглядит безобидно. Финансы закрывают ежемесячные отчёты с помощью трёх связанных таблиц. Операционный отдел собирает запросы через форму, а потом продвигает их дальше с помощью правил почты, которые раскладывают сообщения по нужным ящикам. В обычную неделю всё это кажется достаточно хорошим.

Проблемы начинаются, когда обе команды зависят от одних и тех же цифр. Финансам нужны чистые итоги для закрытия. Операционному отделу нужны актуальные данные по запросам, чтобы планировать заказы, персонал или сроки доставки. Эти два набора данных сходятся в небольшом скрипте, который несколько месяцев назад написал подрядчик.

Этот скрипт соединяет экспорт формы из операционного отдела с таблицами финансов и выдаёт файл, которому люди доверяют. Никто больше не знает, как он работает. Он запускается с компьютера подрядчика, названия полей однажды поменялись без предупреждения, и команда замечает проблему только тогда, когда цифры начинают выглядеть странно.

Первый внутренний аудит портфеля приложений поставил бы этой схеме высокую оценку и по использованию, и по риску. Использование высокое, потому что обе команды часто касаются процесса и опираются на результат при принятии решений. Риск высокий, потому что логика принадлежит одному человеку, передача частично ручная, а сбой случается прямо в середине закрытия.

Красные флаги заметить несложно:

• Только один подрядчик может исправить скрипт
• Три связанных таблицы могут сломаться, если кто-то переименует лист или столбец
• Правила почты трудно увидеть и легко забыть
• Нет общего журнала, который показывает, корректно ли прошла связка данных

Команде не нужен большой пересбор перед концом квартала. Ей нужно просто убрать самое слабое место в передаче. Практичное решение — перенести скрипт в общедоступное место, задокументировать входные данные, назначить резервного владельца и заменить цепочку правил почты одним понятным пунктом входа, который обе команды смогут проверять.

Это изменение не сделает процесс красивым. Оно сделает его безопаснее. Когда наступит загруженный квартал, финансы смогут закрыться без поисков подрядчика, а операционный отдел будет уверен, что запросы в отчёте совпадают с теми, что действительно пришли.

Ошибки, которые только тратят время обзора

Чаще всего команды теряют время ещё до того, как находят хоть один реальный риск. Они открывают пустую таблицу, спорят о столбцах и пытаются придумать идеальный трекер. Обычно это тормозит работу сильнее, чем помогает. Грубого списка с названием инструмента, владельцем, пользователями и назначением достаточно, чтобы начать.

С названиями начинается другая бесполезная ссора. Люди полчаса решают, является ли что-то рабочим процессом, отчётом, скриптом или мини-приложением. Пока это неважно. Если никто не может сказать, кто владеет инструментом, кто пользуется им каждую неделю и что сломается, если он остановится, ярлык не спасёт ситуацию.

Самые опасные инструменты часто выглядят слишком маленькими, чтобы иметь значение. Одна таблица, с которой работает только payroll, один скрипт, который менеджер по продажам запускает по пятницам, одна форма, которую операционный руководитель собрал три года назад, — именно такие вещи ломаются в самый плохой момент. Если инструмент понимает только один человек, ставьте его в список первым, а не последним.

Оценка риска таблиц тоже идёт не так, когда менеджеры ставят оценки из переговорной комнаты. Ежедневные пользователи знают, куда люди вставляют данные вручную, где ломаются выгрузки и к какому файлу все боятся прикасаться. Пять минут с тем, кто пользуется инструментом каждый день, дадут больше пользы, чем аккуратная таблица оценок, собранная на догадках.

Ещё одна частая ошибка — переносить очевидные единые точки отказа на потом. Команды говорят: «Мы разберём это после обзора», хотя уже знают, в чём проблема:

• пароль знает только один человек
• один файл лежит только на одном ноутбуке
• один скрипт работает без подстраховки
• один шаг согласования зависит от того, что один сотрудник находится онлайн
• у одного источника данных нет резервного варианта

Эти проблемы не требуют дополнительного обсуждения. Отмечайте их сразу и ставьте срок.

Внутренний аудит портфеля приложений должен помочь увидеть, где работа может остановиться в загруженный квартал. Если обзор превращается в упражнение по классификации, он уходит в сторону. Держите всё просто, разговаривайте с людьми, которые делают работу, и относитесь к хрупким инструментам, зависящим от одного человека, как к срочным, пока у вас ещё есть время что-то исправить.

Быстрые проверки перед тем, как зафиксировать список

Перед тем как зафиксировать список, приведите в порядок те места, где обычно остаётся размытость. Большая часть работы по обзору рушится в конце, потому что у инструмента три неофициальных владельца, нет запасного варианта и нет срока, к которому нужно устранить проблему, с которой все согласились.

Начните с ответственности. У каждого инструмента должен быть один названный человек, который быстро ответит на простые вопросы: кто этим пользуется, что сломается, если он остановится, и кто утверждает изменения. Команда может поддерживать инструмент, но один человек должен владеть записью. Совместная ответственность звучит справедливо и обычно приводит к молчанию.

Высокорискованным инструментам нужен план подстраховки до начала загруженного квартала. Он не обязан быть сложным. Ежедневный экспорт, копия только для чтения, ручной обходной путь или второй человек, который знает процесс, часто уже достаточны. Если зарплата, отчётность, согласования или клиентские операции зависят от одной таблицы или одного скрипта, не оставляйте восстановление на память.

Командам также нужна чёткая граница для изменений. Некоторые инструменты лучше заморозить на время квартала, если только владелец и руководитель не одобрят обновление. Это особенно важно для инструментов, которые питают финансы, операционную работу или доставку клиентам. Небольшое изменение в неправильной таблице может за один день разойтись по трём командам.

Для самых рискованных инструментов пишите даты исправления и имена владельцев простым языком. Избегайте заметок вроде «потом пересмотреть» или «обсудить в команде». Запишите, кто будет действовать, что именно он изменит и к какому сроку. Если никто не хочет видеть своё имя рядом с инструментом, это тоже полезная информация.

Одностраничное резюме помогает руководителям увидеть картину целиком, не копаясь в десятках вкладок. Держите его коротким:

• название инструмента и бизнес-назначение
• назначенный владелец
• уровень риска
• статус резервного решения
• следующий шаг с датой

Короткий пример делает разрыв очевидным. Финансы могут опираться на рабочую книгу для закрытия, собранную одним аналитиком, а операционный отдел — на скрипт, который понимает только один менеджер. Зафиксируйте владельца рабочей книги, назначьте резервного человека, заморозьте изменения в скрипте операционного отдела и поставьте реальные даты для обоих исправлений. Это занимает меньше времени, чем объяснять пропущенный срок в середине забитого квартала.

Что сделать в ближайшие две недели

Начните с инструментов, которые могут привести к пропущенной оплате, ошибочному отчёту или поломке передачи между командами. Оставьте безобидную уборку на потом. Растущей компании не нужен идеальный список прямо сейчас. Ей нужно меньше способов, которыми загруженный квартал может пойти наперекосяк.

Для первого внутреннего аудита портфеля приложений держите работу короткой и практичной:

• Выберите 5–10 инструментов с наибольшим влиянием на бизнес.
• Назначьте каждому из них одного владельца.
• Уберите одну очевидную точку отказа в каждом инструменте.
• Перенесите хрупкие скрипты в поддерживаемый рабочий процесс.
• Раз в месяц быстро проверяйте всё новое, что появилось вне утверждённых систем.

Третий шаг важнее, чем кажется. Одна таблица с ручным копированием и вставкой, одна форма, которая отправляет письмо не тому человеку, или один скрипт, который запускается только с одного ноутбука, могут создать часы уборки, когда объём вырастет.

Хрупкие скрипты заслуживают особого внимания. Если один человек запускает скрипт со своего компьютера, компания на самом деле не владеет этим процессом. Перенесите его в запланированную задачу, общий репозиторий или другую поддерживаемую схему, которую команда сможет видеть и обслуживать. Даже простая передача дел и один резервный владелец могут быстро снизить риск.

Небольшой пример из финансов и операционной работы делает это понятнее. Если финансы закрывают цифры в таблице, а операционный отдел обновляет запасы через локальный скрипт, не тратьте следующую неделю на переименование вкладок или очистку старых папок. Сначала убедитесь, что цифры берутся из правильного источника, у скрипта есть владелец, и что кто-то ещё сможет его запустить, если обычного человека не будет на месте.

Потом сделайте обзор повторяемым. Поставьте в календарь ежемесячную 30-минутную проверку. Задавайте каждой команде один простой вопрос: какую новую таблицу, форму, скрипт или побочный инструмент вы начали использовать в этом месяце? Так вы рано заметите теневые инструменты, ещё до того, как они превратятся в зависимость.

Держите процесс достаточно маленьким, чтобы команды захотели повторять его снова. Если список продолжает расти, владельцы остаются неясными, а выбор автоматизаций множится, Oleg Sotnikov может помочь как fractional CTO. Это как раз та работа, где понятная ответственность и несколько сильных решений экономят много лишней боли.