ИТ-чекап, ИТ-аудит или ИТ-консалтинг: какой инструмент выбрать собственнику

В реальной жизни собственник редко говорит: «нам нужен ИТ‑чекап» или «давайте делать аудит». Он спрашивает почему тормозит 1С, что делать, если пропали данные, как понять, работает ли бэкап, что будет, если завтра уволится админ. В ответ обычно прилетает: «сервер слабый, надо брать новый», «давайте все обновим», «без большого проекта тут не обойтись». 

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

Меня зовут Авдей Мартынович, я руковожу направлением по работе с малым и средним бизнесом в ALP ITSM. Эта статья для собственников и директоров малого и среднего бизнеса, которые не живут в ИТ‑терминах, а просто хотят разобраться что происходит с ИТ. Ниже разбираю на живых примерах, когда достаточно короткой проверки, когда нужен полноценный разбор, а когда уже есть смысл говорить про проект и сопровождение изменений. 

Шесть ситуаций, в которых может оказываться собственник

Прежде чем выбирать инструмент, нужно понять свою ситуацию. У большинства проблем с ИТ есть характерные симптомы. Вот шесть наиболее частых сценариев, с которыми сталкиваются собственники.

Ситуация 1. «Не понимаю, что вообще происходит с ИТ»

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

Типичная фраза: «Вроде работает, но как-то все на честном слове».

Что нужно: сориентироваться. Понять масштаб, направление, есть ли вообще критические риски.

Ситуация 2. «Тормозит 1С, никто не может объяснить почему»

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

Типичная фраза: «Каждый день в 11:00 1С тупит и все уже привыкли».

Что нужно: найти точную причину. Это могут быть запросы к базе, блокировки, дисковая подсистема, сеть, неоптимальный код в самой 1С. Без технического анализа — гадание.

Ситуация 3. «Все держится на одном айтишнике»

Признаки: пароли в голове у одного человека. Документации нет. Отпуск админа — стресс для компании. Обсуждать с ним передачу дел неудобно (он же обидится).

Типичная фраза: «Если Вася уволится — все встанет».

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

Ситуация 4. «Бэкапы вроде есть, но никто не пробовал восстанавливаться»

Признаки: на вопрос про бэкапы админ подтверждает, что они выполняются. На вопрос «когда последний раз восстанавливали и проверяли, что данные читаются» внятного ответа нет.

Типичная фраза: «Ну, копии же ночью копируются. Должны работать».

Что нужно: убедиться, что в случае сбоя бизнес встанет на ноги. Если резервные копии битые или содержат не то, что нужно, в момент аварии узнать об этом будет поздно.

Ситуация 5. «Готовимся к крупным изменениям»

Признаки: впереди миграция в облако, импортозамещение, внедрение ERP, отделение от материнской компании. Решение принято, нужен план. Цена ошибки — простой, потеря данных, сорванные сроки.

Типичная фраза: «Через полгода уходим с зарубежного софта. Как это сделать без остановки отгрузок?»

Что нужно: проектная работа с архитектурой и сопровождением изменений. Не «понять, что у нас», а «спроектировать, как должно быть и довести до результата».

Ситуация 6. «ИТ-отдел работает, но непонятно, насколько эффективно»

Признаки: заявки решаются медленно, жалоб от сотрудников много, метрик нет. ИТ-руководитель просит расширить штат. Обоснованно или нет — собственник решить не может.

Типичная фраза: «Плачу 300 / 500 тысяч / миллион  в месяц на ИТ, а толку не вижу».

Что нужно: посмотреть на ИТ-процессы со стороны. Понять, где время тратится впустую, какие задачи можно автоматизировать, насколько обоснованы запросы на ресурсы.

Три инструмента, которые помогут

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

ИТ-чекап: быстрая диагностика без доступа к серверам

Чекап — это экспресс-диагностика через интервью. Команда подрядчика проводит две встречи: одну с собственником, одну с ИТ-специалистом. Полтора часа каждая. На серверы никто не подключается, пароли не запрашиваются, инфраструктуру не трогают.

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

На выходе собственник получает отчет на 3–5 страниц на языке бизнеса. Список рисков, узких мест, приоритетов и рекомендаций к действию. Без технического жаргона.

Срок: 3–5 рабочих дней. Средняя стоимость такой услуги порядка 50 000 рублей.

Что чекап не делает. Не находит технических причин конкретных сбоев, т.к. для этого нет доступа к системам. Не разрабатывает решений. Не внедряет изменений. Это диагностика, а не лечение.

ИТ-аудит: детальный технический разбор

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

Аудит может включать разные направления. 

• Комплексный аудит — это инвентаризация всего ИТ-ландшафта. 

• Технический аудит — разбор серверов, систем хранения, сети и баз данных. 

• Аудит безопасности — проверка устойчивости к взлому, анализ уязвимостей, тестирование резервного копирования и защиты данных. 

• Отдельно при необходимости проводят аудит ИТ‑процессов (например, как устроена работа с инцидентами, запросами на обслуживание, изменениями) и 

• аудит ИТ‑команды — роли, компетенции, нагрузка, узкие места в управлении.

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

Срок: 2–8 недель в зависимости от глубины. Средняя вилка стоимости в зависимости от объема от 200 000 до 800 000 рублей.

Еще раз хочу отметить, что это не только технический разбор, но и работа с процессами и командой, кто за что отвечает, каких компетенций не хватает. 

Что аудит не делает. Не внедряет рекомендации сам. Аудитор показывает, что и как нужно исправить, но реализацией занимается либо ваша команда, либо отдельный проект. 

ИТ-консалтинг: проектирование и сопровождение изменений

Консалтинг — это полноценная проектная работа, когда подрядчик встраивается в команду и доводит изменения до результата. Это уже не «найдите, что не так» и не «составьте список рекомендаций». Это «спроектируйте новое, помогите внедрить, доведите до работающего состояния».

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

Срок: от 4 недель, обычно несколько месяцев. Стоимость считается по проекту, в небольших проектах стоимость на такие работы начинается от 500 тыс. руб.

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

Как ИТ-чекап работает на практике: три истории

Чтобы теория не висела в воздухе, разберу три случая из практики. Компании из разных сфер и разного масштаба, общая часть одна: на ИТ-чекапе всплывают вещи, о которых ни собственник, ни ИТ-команда раньше не задумывались. Названия и имена скрыты.

История 1. Бэкапы делаются, но никто не знает, рабочие ли они

Производственная компания, около 200 сотрудников. Вся инфраструктура держалась на одном администраторе. Собственник был спокоен: «У нас же бэкапы каждую ночь, все под контролем».

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

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

Что рекомендовали. Создать регламент регулярной проверки консистентности и возможности восстановления. Назначить ответственного. Дублировать критические доступы — чтобы система не зависела от одного человека. Эти решения собственник внедрил с командой за следующие два месяца. Без аудита, своими силами, по чек-листу.

История 2. Бизнес и ИТ годами говорили на разных языках

Розничная сеть, около 40 точек. Магазины периодически зависали, бизнес терял выручку из-за простоев касс. Собственник хотел понять, где именно проблема.

Что показал чекап. На встрече собственник сформулировал требование: «Если 1С падает — мы должны подняться максимум за час, иначе теряем дневную выручку». Через день мы встретились с ИТ-командой и спросили то же самое: «За сколько вы реально восстановите 1С при серьезном сбое?» Ответ: «Часа за четыре, если повезет».

Бизнес ставит время восстановления в 1 час, ИТ может обеспечить 4 часа. Все ходят и не подозревают о расхождении, пока не случится первый серьезный сбой и не выяснится: вместо обещанного часа простоя магазины стоят полдня.

Что рекомендовали. Зафиксировать требования бизнеса по времени восстановления в письменном виде. Провести узкий технический аудит резервного копирования и архитектуры 1С — посмотреть, за счет каких изменений сократить реальное время восстановления. По итогам аудита внедрить изменения и согласовать реалистичный SLA. Здесь чекап стал входной точкой для следующего шага — фокусного аудита с конкретной целью.

История 3. Бизнес без ключей от собственного сайта

Онлайн-ретейлер с одной командой разработки. Сайт — единственный источник дохода. Команда работала обособленно, отчетности нет, что происходит — собственник не понимал.

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

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

Что рекомендовали. Собрать карту критичных доступов на стороне собственника. Перевести регистратор домена на корпоративный аккаунт. Подключить независимый внешний мониторинг доступности сайта. Прописать регламент передачи доступов при увольнении ключевых сотрудников.

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

Три инструмента в одной таблице

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

Какой инструмент подходит под вашу ситуацию

Частый сценарий, когда собственник выбирает инструмент не под задачу. Заказывает аудит, когда хватило бы короткой диагностики. Берет чекап, когда уже давно назрел разбор «под микроскопом». Ниже шесть типовых ситуаций и то, что с ними обычно работает.

«Не понимаю, что происходит» → чекап

Когда непонятно, в каком состоянии ИТ, то заказывать дорогой аудит за 500 тысяч преждевременно. Сначала нужен чекап — короткая диагностика, после которой либо станет ясно, что критических проблем нет (и можно расслабиться), либо появится понятная задача для следующего шага.

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

«Тормозит 1С» → сразу технический аудит

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

Без полного доступа к серверам и СУБД эти вопросы не решить. Цена такого аудита 1С может быть в пределах 200–400 тысяч рублей, но часто экономит миллионы на ненужном новом железе.

«Все держится на одном айтишнике» → чекап

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

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

«Бэкапы непонятно как работают» → чекап, потом узкий аудит

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

Если же проверки формально есть, но бизнес не уверен, что в случае реального сбоя все восстановится корректно — нужен узкий аудит резервного копирования. Аудитор тестирует восстановление на отдельной площадке, проверяет полноту копий, измеряет реальное время восстановления. Такой аудит обычно стоит в районе 100–200 тысяч.

«Готовимся к крупным изменениям» → консалтинг

Переезд в облако, импортозамещение, внедрение ERP, отделение от материнской компании — это уже проект, а не просто проверка. Здесь нужен консалтинг.

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

«Не понимаю, эффективно ли работает ИТ-команда» → аудит процессов

Здесь вопрос не в серверах, а в работе людей. Нужен аудит процессов.

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

Как эти три инструмента сочетаются между собой

Часто кажется, что чекап, аудит и консалтинг — это лестница, по которой нужно пройти все три ступеньки. Это не так. У каждого инструмента — своя роль, и в конкретной ситуации может понадобиться только один.

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

•     критических рисков немного, рекомендации внедряются силами своей команды по чек-листу;

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

•     выявлена системная задача (миграция, импортозамещение, перестройка процессов) — следующий шаг консалтинг;

•     выясняется, что ИТ-подрядчик не справляется — собственник меняет подрядчика с понятным брифом на руках.

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

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

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

На что обращать внимание при выборе подрядчика

Выбор инструмента — это половина дела. Вторая половина — кому доверить работу. Несколько ориентиров:

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

Подрядчик честно говорит, что в его инструмент не входит. «Чекап покажет направление, но не найдет конкретную причину тормозов 1С, для этого нужен аудит» — нормальный ответ. «Мы решим все ваши проблемы за один проект» — повод насторожиться.

Подрядчик не пытается продать максимально дорогую услугу с порога. Если на запрос вам сразу предлагают комплексный аудит на сотни тысяч — стоит спросить, нет ли более дешевого способа сориентироваться. Если ответ «нет» — это маркер.

У подрядчика есть методология, а не «опытный взгляд». Опыт важен, но он не должен быть единственным аргументом. Если вы спрашиваете, как именно подрядчик работает, а в ответ слышите только «у нас 15 лет на рынке и крутые специалисты» — это тревожный сигнал. Должен быть понятный регламент: какие вопросы задаются, как анализируются ответы, как формируется отчет.

Цена фиксирована до начала работ. Особенно для чекапа и аудита.

Вместо заключения: алгоритм собственника

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

Сначала сформулируйте, что у вас в компании не так с ИТ: где теряете время и деньги, какие симптомы видите, что уже пробовали, что говорит команда. Чем точнее формулировка, тем меньше лишних движений по пути к решению.

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

ИТ давно перестало быть просто обслуживающей функцией. Это основа бизнеса, и решения по ней лучше принимать на основе понятной картины, а не по ощущению «кажется, все нормально».