Топ-10 рисков, которые ИТ-директора игнорируют до последнего момента

1. Вендорлок — корпоративная версия

Что происходит: Ты годами строишь всю инфраструктуру на одном вендоре. Oracle базы? Давай и сервера их возьмем! И аналитику! И CRM! Так удобнее же!

Почему это ад: В один прекрасный день вендор поднимает цены на 40%, а ты такой “ну и что мне теперь делать?” — НИЧЕГО. Ты в ловушке, котан. Миграция будет стоить столько, что проще заплатить.

Реальный кейс: Одна компания из ритейла так залипла на SAP, что когда им выкатили новый прайс после начала спецоперации, они просто молча заплатили космические деньги, потому что альтернатива — это пиздец разработка сроком на 2 года.

Как избежать: Строй архитектуру с учетом возможности замены компонентов. Да, это сложнее и дороже прямо сейчас, но это страховка на будущее. И документируй интерфейсы между системами, чтобы потом не гадать, как оно работает.

2. Технический долг, который никто не собирается отдавать

Что происходит: “Давай быстро запилим MVP, а потом перепишем нормально”. Спойлер: никто никогда ничего не перепишет, пока оно работает.

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

Реальный кейс: Собеседовался в крупную сеть по продаже колес и дисков, которая годами жила на “временном решении” — 12 баз 1С:Торговля и Склад 7.7 без единой шины данных, обменивающихся запросами напрямую друг с другом. За три года сменилось 4 ИТ-директора. Документации ноль, описания бизнес-процессов тоже. WMS система куплена, но реально интегрировать её в этот самодельный хаос невозможно. Система падала дважды в день, а в пик продаж заказы собирали вручную. Сил и терпения тому ИТ-директору, кто решится взяться за этот технический долг размером с экватор.

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

3. Отсутствие DRP — авось пронесет

Что происходит: Все знают, что нужен план восстановления после катастроф, но никто его не тестирует. Потому что “ну когда у нас последний раз датацентр горел?”

Почему это недальновидно: Когда случится пиздец (а он случится), ты будешь стоять с открытым ртом и думать, почему резервные копии не восстанавливаются, а документация устарела на два года в лучшем случае (если она у тебя вообще была).

Реальный кейс: В одном из подразделений МВД потеряли всю аналитическую базу за 5 лет работы — резервные копии оказались битыми, потому что никто никогда не проверял процедуру восстановления. Простой отдела — 14 дней, потери в виде утраченных данных расследований, статистики и аналитических отчетов вообще невозможно оценить в деньгах.

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

4. У нас всё безопасно — главная ложь ИТ

Что происходит: Безопасность воспринимается как галочка в чеклисте, а не как процесс.

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

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

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

5. Зависимость от “незаменимых” сотрудников 🧙‍♂️

Что происходит: В компании есть Вася, который 10 лет назад написал ядро системы и только он знает, как оно работает. Все боятся его трогать, потому что “а вдруг уйдет”.

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

Реальный кейс: В компании по тепловому оборудованию программист писал собственную CRM и стал единственным, кто в ней разбирался (и кто додумался до такого). Когда он начал просить слишком много денег за свой талант, собственник прям так и сказал: “Незаменимых нет — увольняем”. Потом собственник два года безуспешно пытался реанимировать и разобраться в системе с помощью вороха аутсорсеров, кого-то даже нанимал в штат. Но учить чужой говнокод желающих мало. Потом у него кончились деньги и энтузиазм. Переписать все системы расчета с нуля оказалось неподъемно дорого. Компания фактически оказалась заложником одного уволенного разработчика и сгинула.

Как избежать: Принцип автобуса (если сотрудника собьет автобус, компания должна выжить). Ротация задач, парное программирование, обязательная документация и code review. И никогда не позволяй одному человеку стать единственным владельцем критически важной системы — это прямая дорога к корпоративному шантажу.

6. Игнорирование требований регуляторов

Что происходит: ИТ-директор считает, что 152-ФЗ или прочие регуляторные требования — это просто бумажки, которые можно проигнорировать.

Почему это бомб: Пока игнорируешь регуляторов, они не игнорируют тебя. Штрафы могут доходить до 4% от годового оборота компании. Это дохуя, если что компания может и не пережить.

Реальный кейс: Погугли на досуге кикие штрафы последние два года выписывали в России.

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

7. Облака решат все проблемы — новая религия

Что происходит: “Давай всё перенесем в облака, и будет нам счастье!” — без анализа, что именно нужно переносить и зачем.

Почему это закончиться плохо: Внезапно оказывается, что счета за облака в 3 раза выше, чем ты планировал, а производительность ниже, потому что архитектура не оптимизирована под облачную инфраструктуру. Увы, но там всё работает быстрее только первое время.

Реальный кейс: Мой близкий друг работает в компании-подрядчике Subway, где на лямбда-функциях написаны тонны вещей, их счета за Amazon съедают большую часть прибыли. Увы, чела, что это писал, они уже уволили, пакистанцы медленно переписывают код.

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

8. Недооценка человеческого фактора

Что происходит: Внедряется новая система, но на обучение и адаптацию пользователей забивают. Интерфейс интуитивно понятный, разберутся же!

Почему это не так: Люди не используют систему или используют неправильно. Данные становятся мусором, решения принимаются на основе неверной информации.

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

Как избежать: Вовлекай пользователей на этапе проектирования. Проводи нормальное обучение. Собирай обратную связь! И помни: успех проекта определяется не технологией, а тем, используют ли её люди.

9. Отсутствие метрик — у нас всё хорошо, наверное)

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

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

Реальный кейс: ИТ-отдел годами развивал функциональность, которую успешно саботировали как те, кто должен ею пользоваться, так и те, кто должен был за этим следить. В итоге реально пользовалось 5% сотрудников, игнорируя критические проблемы остальных 95%. Узнали об этом только после внедрения аналитики использования, к этому моменту уже были потрачены миллионы на разработку и поддержание.

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

10. Игнорирование пользовательского опыта — это же внутренняя система

Что происходит: Внутренние системы делаются по принципу “и так сойдет”. Интерфейс из 90-х, 10 кликов для простой операции, тормоза и баги.

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

Реальный кейс: Одна компания разработала внутреннюю CRM, которая была настолько плохой, что менеджеры вели клиентов в Excel.

Как избежать: Относись к внутренним пользователям как к клиентам. Проводи UX-исследования, тестируй прототипы на них же. Собирай обратную связь. И помни: если система не удобная, люди не будут ей пользоваться.

Бонус: “Это не мой департамент” — синдром корпоративной близорукости

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

Почему это повод тебя уволить: Технологии ради технологий — путь в никуда. Если ты не понимаешь, как твои системы влияют на бизнес, ты просто тратишь деньги компании. Всё!

Реальный кейс: ИТ-директор гордился микросервисной архитектурой на symfony php, пока ИТ сжигал деньги стартапа, а бизнес терял клиентов из-за того, что базовые функции внедряли по полгода. Итог, деньги кончились раньше, чем наростили прибыль. Golama, пока 👋

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

Вместо заключения: как не облажаться

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

Главное правило: ИТ существует для поддержки бизнеса, а не наоборот. Каждое решение должно проходить проверку: “Как это поможет нашим клиентам или сотрудникам?”

И помни, котан: лучше предотвратить пиздец, чем героически его разгребать.

Нестареющая классика