IT-аудит - Portfolio https://shknv.ru Евгений Шикунов Sat, 25 Apr 2026 13:28:57 +0000 ru-RU hourly 1 https://wordpress.org/?v=6.9.4 https://shknv.ru/wp-content/uploads/2024/12/web-app-manifest-512x512-1-150x150.png IT-аудит - Portfolio https://shknv.ru 32 32 Как мы навели порядок в отделе автоматизации за 6 месяцев: кейс без показной героики https://shknv.ru/it-transformation-case/ Mon, 20 Apr 2026 09:00:00 +0000 https://shknv.ru/?p=580 Разбор реальной трансформации отдела автоматизации: как уйти от вечного аврала, входящих задач из мессенджеров и недоверия бизнеса к понятной операционной модели с результатом в цифрах.

The post Как мы навели порядок в отделе автоматизации за 6 месяцев: кейс без показной героики first appeared on Portfolio.

]]>

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

  • Время чтения: 11 минут
  • Формат: практический разбор без лишней теории

Что внутри:

Когда компания говорит, что у неё «не справляется IT», очень часто проблема не в людях и не в том, что кто-то недостаточно старается. Проблема в том, что отдел живёт без операционной модели. Задачи прилетают отовсюду, приоритеты никто не держит, срочное побеждает важное, а бизнес видит только одно: заявки закрываются медленно, прозрачности нет, команда всё время в напряжении.

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

Что было на старте

Если коротко, то стартовая картина выглядела знакомо для многих компаний:

  • накопленный хвост задач без сроков и владельцев;
  • несколько каналов входа: звонки, Telegram, WhatsApp, личные договорённости;
  • отсутствие понятного цикла работы по задачам;
  • слабая связь между запросом бизнеса и реальной загрузкой команды;
  • отчётность по работе отдела собиралась вручную и не вызывала доверия.

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

С чего мы начали на самом деле

Мы не начинали с громких обещаний и не пытались сразу «внедрить Agile». Первой задачей была диагностика.

Нужно было понять три вещи:

  1. Какие типы задач реально приходят в отдел.
  2. Где именно теряется управляемость.
  3. Что мешает руководителю защищать приоритеты перед бизнесом.

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

Почему хаос не лечится одной доской задач

Это важное наблюдение. Многие компании думают так: «У нас бардак, значит нужно поставить таск-трекер». Но таск-трекер не решает проблему сам по себе. Если в отдел по-прежнему можно прийти в обход процесса, писать в личку или проталкивать задачи через эмоциональное давление, хаос просто перемещается в другую оболочку.

Поэтому мы собирали решение из нескольких слоёв.

1. Единая точка входа

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

Это оказалось неприятным только первые недели. Потом команда и бизнес почувствовали эффект: стало видно реальное количество входящих запросов, типы работ и узкие места.

2. Общее правило приоритизации

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

Это снизило шум сильнее, чем любой новый инструмент.

3. Роли и зоны ответственности

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

Мы помогли распределить зоны ответственности так, чтобы появились владельцы процессов, аналитики на стороне коммуникации с бизнесом и более понятный контур делегирования у руководителя.

4. Ритм работы

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

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

Что меняется после наведения порядка

Самое интересное в таких проектах — эффект ощущается не только внутри IT.

Для команды:

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

Для руководителя отдела:

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

Для бизнеса:

  • запросы становятся прозрачнее;
  • ожидания по срокам реалистичнее;
  • ценность IT-функции заметнее.

Какие метрики действительно важны

В этом проекте мы сознательно не гнались за десятками показателей. Для управляемости хватило нескольких вещей:

  • размер актуального backlog;
  • доля задач с понятным владельцем и сроком;
  • время реакции на разные типы запросов;
  • количество завершённых инициатив по сравнению с хаотичными входящими;
  • время, которое команда тратит на ручную отчётность.

Когда эти цифры становятся видимыми, разговор внутри компании взрослеет. Вместо «IT опять ничего не успевает» появляется возможность обсуждать ресурсы, приоритеты и ограничения на языке фактов.

Что оказалось самым сложным

Сложнее всего обычно не настроить систему и не провести стендап. Сложнее изменить привычки.

Бизнесу нужно перестать ходить в обход процесса. Руководителю отдела — перестать быть единственным фильтром всех задач. Команде — перестать воспринимать срочное как норму.

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

Что мы считаем реальным результатом

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

Команда получила:

  • меньший объём накопленного хаоса;
  • более понятный backlog;
  • регулярный ритм;
  • прозрачность статуса задач;
  • заметное сокращение времени на ручные отчёты.

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

Кому полезен такой подход

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

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

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

Вывод

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

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

Именно это мы и считаем нормальной зрелой целью.

Связанные материалы

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

The post Как мы навели порядок в отделе автоматизации за 6 месяцев: кейс без показной героики first appeared on Portfolio.

]]> Как новому IT-руководителю навести порядок за первые 8 недель: практический маршрут без лишнего шума https://shknv.ru/it-department-first-8-weeks/ Mon, 20 Apr 2026 09:00:00 +0000 https://shknv.ru/?p=583 Статья для тех, кто приходит в IT-отдел, где задачи живут в чатах, приоритеты меняются ежедневно, а бизнес недоволен скоростью. Пошагово разбираем первые 8 недель: что смотреть, чего не делать и как показать быстрый, но честный результат.

The post Как новому IT-руководителю навести порядок за первые 8 недель: практический маршрут без лишнего шума first appeared on Portfolio.

]]>

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

  • Время чтения: 10 минут
  • Формат: практический разбор без лишней теории

Что внутри:

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

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

Недели 1–2. Не реформируйте то, чего ещё не поняли

Первые две недели — это не время для больших обещаний. В это время нужно собрать картину.

Что важно посмотреть:

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

Очень полезно провести короткие беседы 1:1 не только с сотрудниками IT, но и с ключевыми заказчиками из бизнеса. Обычно именно там слышно главное: где боль, где недоверие и где иллюзии.

Главная ошибка этого этапа — сразу начинать лечить симптомы. Например, ставить новую систему задач ещё до того, как понятно, почему старая не работает.

Недели 3–4. Зафиксируйте правила игры

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

На этом этапе я бы сфокусировался на четырёх вещах:

1. Единый вход для задач

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

2. Понятная классификация работ

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

3. Видимый backlog

Руководитель должен видеть не только то, что уже взяли в работу, но и то, что стоит в очереди. Иначе невозможно обсуждать приоритеты честно.

4. Короткий набор метрик

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

  • объём входящих задач;
  • текущий backlog;
  • скорость реакции на разные типы запросов;
  • долю задач с понятным владельцем и сроком.

Недели 5–6. Соберите рабочий ритм команды

Многие думают, что проблема IT-отдела решается наймом дополнительных людей. Иногда это правда. Но очень часто сначала нужно уменьшить хаос.

Здесь важен ритм. Команда должна жить не только реакцией на входящее, но и короткими циклами планирования. Формат может быть разным, но суть одна:

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

Я осторожно отношусь к словам «внедрим Scrum», потому что у компаний под этим бывает много ожиданий. Но если убрать термины, то руководителю нужны вполне понятные вещи: предсказуемость, обозримость работы и возможность не решать всё на эмоциях.

Недели 7–8. Покажите первый осмысленный результат

К восьмой неделе у руководства должен появиться ответ на вопрос: стало ли понятнее, как работает IT-функция.

Не обязательно к этому моменту запускать большую трансформацию. Но уже можно показать:

  • из каких типов задач состоит поток;
  • сколько задач входит и сколько реально можно переварить;
  • какие процессы больше всего ломают управляемость;
  • какие 2–3 изменения дали быстрый эффект;
  • что нужно делать дальше и почему.

Это и есть взрослая управленческая коммуникация. Не «мы очень стараемся», а «вот текущее состояние, вот риски, вот план, вот первые результаты».

Какие быстрые победы обычно работают

За первые 8 недель чаще всего дают эффект не крупные проекты, а изменения в операционном контуре:

  • единый приём заявок;
  • приоритизация backlog;
  • прозрачная доска работы;
  • базовая автоматизация отчётности;
  • убирание дублирующих ручных операций;
  • инвентаризация систем и владельцев.

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

Чего делать не стоит

Есть несколько ошибок, которые дорого обходятся новому руководителю:

Сразу обещать большой прорыв

Если вы ещё не понимаете глубину проблем, любые точные обещания — это ставка вслепую.

Делать ставку только на инструмент

Новый таск-трекер, новая wiki, новые шаблоны — всё это может помочь, но не заменяет управленческих правил.

Попытаться лично контролировать всё

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

Игнорировать политику и ожидания бизнеса

IT-отдел не живёт отдельно от компании. Нужно понимать, кто влияет на приоритеты, где чувствительные зоны, какие обещания уже даны и какие конфликты тянутся давно.

Как понять, что вы двигаетесь правильно

Хороший сигнал — когда через 6–8 недель становится меньше шума, а не больше. Это может проявляться в простых вещах:

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

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

Вывод

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

Это не выглядит как революция. Зато именно так обычно и начинается нормальная зрелая IT-функция, которая потом уже может заниматься развитием, а не вечным спасением ситуации.

Связанные материалы

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

The post Как новому IT-руководителю навести порядок за первые 8 недель: практический маршрут без лишнего шума first appeared on Portfolio.

]]> Когда бизнесу нужен IT-аудит, а не ещё одна новая система https://shknv.ru/it-audit-or-new-system/ Mon, 20 Apr 2026 09:00:00 +0000 https://shknv.ru/?p=584 Во многих компаниях желание купить новую платформу возникает раньше, чем понимание реальной причины проблем. Разбираем, когда бизнесу нужен IT-аудит, какие вопросы он должен снять и почему это часто дешевле неправильного внедрения.

The post Когда бизнесу нужен IT-аудит, а не ещё одна новая система first appeared on Portfolio.

]]>

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

  • Время чтения: 10 минут
  • Формат: практический разбор без лишней теории

Что внутри:

Один из самых дорогих сценариев в цифровых проектах выглядит очень логично со стороны бизнеса: в компании есть проблемы, значит нужна новая система. На этом месте обычно начинают сравнивать CRM, ERP, service desk, BI или какую-нибудь «единую платформу».

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

Именно поэтому в ряде случаев правильный первый шаг — не внедрение, а IT-аудит.

Как понять, что вас тянет к неправильному решению

Вот несколько фраз, после которых я почти всегда предлагаю сначала диагностику:

  • «У нас всё разрозненно, давайте поставим что-то единое».
  • «Сотрудники жалуются, что старая система неудобна».
  • «Отчёты не сходятся, значит нужна новая CRM».
  • «Интеграции ломаются, может быть проще всё заменить».

Во всех этих формулировках уже слышно желание перепрыгнуть к инструменту до того, как понятна природа проблемы.

На практике трудности могут сидеть в разных местах:

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

Если не разобрать это заранее, новая система унаследует старые болезни.

Что должен дать нормальный IT-аудит

IT-аудит — это не отчёт на 80 страниц с банальностями. Он должен отвечать на очень конкретные вопросы бизнеса.

1. Где на самом деле находится корневая проблема

Например, руководство думает, что отдел продаж «не работает в CRM». А аудит показывает, что менеджеры не видят актуальные статусы заказов, потому что 1С и CRM живут отдельно и данные расходятся. В таком случае проблема не в дисциплине использования CRM, а в архитектуре процесса и интеграции.

2. Какие системы действительно критичны

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

3. Что можно починить без большой замены

Иногда реальный эффект даёт не покупка новой платформы, а:

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

4. Где замена действительно оправдана

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

Из чего состоит полезный аудит

Мы обычно смотрим минимум на пять слоёв.

Процессы

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

Данные

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

Системы

Какие контуры уже есть, что они умеют, где дублируют друг друга, где избыточны, а где наоборот отсутствуют.

Интеграции

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

Управление и ownership

Кто принимает решения по изменениям, кто отвечает за приоритеты, кто может сказать «нет» лишней автоматизации и кто держит картину целиком.

Когда аудит нужен особенно сильно

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

После периода быстрого роста

Компания выросла, процессов стало больше, а цифровой контур остался прежним. В такие моменты важно понять, что сломалось из-за масштаба, а что — из-за отсутствия правил.

Перед крупной заменой системы

Если вы собираетесь менять CRM, ERP или основной интеграционный контур, аудит окупается почти всегда. Он помогает не тащить старые ошибки в новый проект.

Когда данные не вызывают доверия

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

Когда бизнес просит «автоматизировать всё»

Это опасный сигнал. Без диагностики такой запрос обычно ведёт к перегретому проекту с размытым результатом.

Что бизнес часто недооценивает

IT-аудит не должен превращаться в академическое упражнение. Он нужен не ради «красивой диагностики», а ради управленческого решения.

Поэтому хороший итог аудита — не просто список проблем, а маршрут:

  • что исправлять в первую очередь;
  • что пока не трогать;
  • где достаточно доработок;
  • где нужна новая система;
  • какие риски и ограничения есть у каждого сценария.

Именно это позволяет руководству принимать взрослое решение по бюджету и срокам.

Вывод

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

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

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

Связанные материалы

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

The post Когда бизнесу нужен IT-аудит, а не ещё одна новая система first appeared on Portfolio.

]]> Облако или локальная инфраструктура: как выбрать без идеологии и лишних расходов https://shknv.ru/cloud-or-onpremise-for-business/ Mon, 20 Apr 2026 09:00:00 +0000 https://shknv.ru/?p=589 Спор между облаком и on-premise часто ведут как мировоззренческий. Для бизнеса это не вопрос веры, а вопрос экономики владения, рисков, требований к безопасности и зрелости команды.

The post Облако или локальная инфраструктура: как выбрать без идеологии и лишних расходов first appeared on Portfolio.

]]>

Коротко: Спор между облаком и on-premise часто ведут как мировоззренческий. Для бизнеса это не вопрос веры, а вопрос экономики владения, рисков, требований к безопасности и зрелости команды.

  • Время чтения: 10 минут
  • Формат: практический разбор без лишней теории

Что внутри:

В разговорах про инфраструктуру слишком много идеологии. Одни говорят, что всё нужно уносить в облако, потому что так современно и быстро. Другие убеждены, что настоящее управление возможно только тогда, когда всё стоит «у себя».

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

Когда облако действительно выигрывает

У облака есть сильные и вполне прагматичные преимущества.

Быстрота запуска

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

Гибкость масштаба

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

Снижение порога входа

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

Когда локальная инфраструктура оправдана

On-premise не устарел и не является признаком консерватизма. Есть ситуации, где это зрелый и рациональный выбор.

Жёсткие требования к размещению данных

В некоторых отраслях и сценариях вопрос контроля над размещением данных критичен. Иногда это требования регулятора, иногда внутренняя политика безопасности, иногда особенности контракта с заказчиком.

Высокая предсказуемая нагрузка

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

Особые интеграционные и сетевые ограничения

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

Где компании чаще всего ошибаются

Ошибка 1. Смотреть только на стартовый бюджет

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

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

Ошибка 2. Недооценивать стоимость собственной эксплуатации

Фраза «пусть будет у нас на сервере» часто не учитывает, что сервер сам себя не обновляет, не мониторит и не резервирует. Нужны люди, процессы, регламенты и время.

Ошибка 3. Выбирать архитектуру из страха

Иногда компания берёт on-premise просто потому, что «так спокойнее». Иногда — облако, потому что «все так делают». Оба выбора могут оказаться неверными, если не привязаны к реальным ограничениям бизнеса.

Как я бы выбирал на практике

Есть пять вопросов, которые полезно задать до решения.

1. Что у нас с чувствительностью данных

Насколько жёсткие требования к размещению, доступу, журналированию и контролю среды?

2. Что у нас с внутренней командой

Есть ли люди, которые реально способны поддерживать локальную инфраструктуру? И готовы ли вы платить за эту компетенцию постоянно?

3. Какой у нас профиль нагрузки

Нагрузка стабильна или скачет? Нужна ли гибкая эластичность или, наоборот, важнее жёсткий контроль среды?

4. Как быстро нам нужно меняться

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

5. Насколько тесно мы связаны с внутренним контуром

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

Почему гибрид часто оказывается лучшим вариантом

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

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

Такой подход сложнее архитектурно, но часто лучше соответствует реальности бизнеса, чем чистая модель «всё в облако» или «всё в локалку».

Вывод

Выбор между облаком и локальной инфраструктурой — это не спор о моде. Это управленческое решение с очень практическими последствиями.

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

Главное — считать не только первый бюджет и не путать ощущение контроля с реальной экономикой владения.

Связанные материалы

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

The post Облако или локальная инфраструктура: как выбрать без идеологии и лишних расходов first appeared on Portfolio.

]]> Трансформация IT отдела https://shknv.ru/transformacija-it-otdela/ Tue, 14 Oct 2025 06:44:26 +0000 https://shknv.ru/?p=413 Кейс трансформации IT-отдела: как перейти от хаотичных задач и ручной отчетности к понятной операционной модели.

The post Трансформация IT отдела first appeared on Portfolio.

]]>  

От хаоса к системе: история трансформации IT-отдела за 7 месяцев

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

📅 Период: Апрель — Октябрь 2025
👥 Команда: 6+ специалистов
📊 15+ крупных проектов

📌 Ключевой результат

За 7 месяцев работы IT-отдел перешел от состояния «пожарной команды» к предсказуемой системе разработки, внедрив 8 крупных систем, автоматизировав более 25 отчетов и обработав свыше 1,000 инцидентов с высокой скоростью решения.

🎯 С чего всё начиналось: диагностика проблем

Когда я возглавил IT-отдел средней дистрибьюторской компании, передо мной открылась классическая картина: десятки горящих задач, отсутствие приоритизации, недовольные пользователи и команда, работающая в режиме постоянного цейтнота. Всё это сопровождалось типичными симптомами «больного» IT-отдела:

  • Перегрузка очереди: 44 задачи ожидали начала работы без четких дедлайнов и приоритетов
  • Отсутствие системы: Заявки приходили через мессенджеры, звонки и устные просьбы в коридоре
  • Хаос в планировании: Неопределенность сроков, постоянная смена приоритетов, срывы дедлайнов
  • Размытые границы: Руководитель отдела тонул в рутинных задачах, не имея времени на стратегию
  • Технический долг: Проблемы с интернетом, устаревшая инфраструктура, отсутствие документации
  • Низкая видимость: Бизнес не понимал ценности IT-отдела, воспринимая его как «центр затрат»
«Первый и самый важный шаг — признать проблему и превратить её из эмоционального переживания в конкретный список задач с измеримыми метриками успеха.»

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

🔄 Стратегия трансформации: три кита изменений

1. Процессы: от хаоса к Scrum

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

К октябрю 2025 года мы полностью перешли на Scrum-методологию:

  • Двухнедельные спринты с четкими целями и ограничением WIP (work in progress) до 10-15 активных задач
  • Ежедневные стендапы по 15 минут для синхронизации команды
  • Назначен Scrum Master из числа команды для координации процессов
  • Product Owner для 1С — отдельная роль для управления бэклогом основной системы
  • Спринт-ревью и ретроспективы для постоянного улучшения процессов

2. Люди: развитие команды и делегирование

Параллельно с изменением процессов я работал над развитием команды. Ключевые действия:

👔

IT-директор

Стратегия, бюджетирование, взаимодействие с бизнесом

🎯

Product Owner 1С

Координация задач 1С, управление бэклогом, держатель базы

🏃

Scrum Master

Организация Scrum-процессов, 1-я линия поддержки, оценка задач

💻

Developer 1С

Разработка и доработка систем на платформе 1С

📊

BI Analyst

Разработка отчетов Power BI, визуализация данных

📋

Business Analyst

Описание процессов, системный анализ, оптимизация BPMN

🔧

System Administrator

Сеть, безопасность, серверы, инфраструктура

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

3. Технологии: автоматизация и модернизация

Третий кит — обновление технологического стека и автоматизация рутинных процессов. Мы инвестировали в новое оборудование для переноса сервера 1С, запустили миграцию отчетности в Power BI и внедрили современные инструменты разработки.

🎉 Ключевые достижения за 7 месяцев

8
Внедрено систем
31
Процессов описано
25+
Отчетов в Power BI
1,033
Инцидентов решено
5,000+
Визитов в WestVisit
44→20
Снижение очереди

Системы и проекты

  • Система заявок: Централизованная обработка всех запросов через Bitrix24 для IT, юридического и финансового отделов. Полная прозрачность и трекинг каждой заявки.
  • Платежный календарь: Автоматизация согласования расходов. Сократили время согласования платежей на 60%, устранили ручные операции в Excel.
  • Интернет-эквайринг: Внедрили для 15+ водителей с автоматической отправкой чеков. Интеграция с T-pay и Sber-pay, синхронизация с системой Business.ru.
  • WhatsApp AI-бот: Разработали систему распознавания заказов по фотографиям с автоматическим заполнением позиций. Экономия 2-3 часа времени менеджеров ежедневно.
  • WestVisit: Мобильное приложение для визитной активности торговых представителей с интеграцией в 1С и CRM. Зафиксировано более 5,000 визитов.
  • Миграция в Power BI: Перевели 25+ отчетов из ручного режима в автоматические дашборды. Создан корпоративный брендбук для визуализаций. Сокращение времени на формирование отчетов на 70%.
  • Честный знак: Полная интеграция с системой маркировки, включая выпуск собственных кодов. Обеспечили соответствие законодательным требованиям.
  • Парсер цен конкурентов: Автоматический мониторинг ценовой политики конкурентов для отдела продаж.

Процессы и методология

  • 31 бизнес-процесс описан в BPMN: 10 для тендерного отдела, 12 для продаж, 9 для финансов и учебного центра. Создана полная документация текущих процессов (As-is).
  • Внедрение Scrum: Полный переход на спринтовую разработку с октября 2025. Прозрачность, предсказуемость, контроль velocity команды.
  • Матрица приоритизации P0-P3: Четкая система определения важности задач на основе влияния на бизнес и сложности реализации.
  • Реестр доработок 1С: Систематизация всех модификаций основной системы для контроля технического долга.

📊 Измеримое влияние на бизнес

Один из главных вызовов руководителя IT-отдела — доказать ценность для бизнеса. За 7 месяцев мы не просто внедряли технологии, но и измеряли их эффект:

  • -60% времени согласования платежей благодаря автоматизации платежного календаря
  • -70% времени на формирование отчетов после миграции в Power BI
  • 2-3 часа экономии ежедневно для менеджеров по продажам при использовании AI-бота
  • +25% контроль работы торговых представителей через WestVisit
  • -30% снижение количества инцидентов благодаря базе знаний и обучению
  • 95% автоматизация складских операций (в процессе достижения)

К концу периода мы начали работу над каталогом услуг IT-отдела с указанием стоимости и времени на каждую услугу. Цель — демонстрация ROI и трансформация восприятия IT из «центра затрат» в «драйвера роста».

⚠ Проблемы и препятствия на пути

Трансформация — это не только успехи, но и регулярные проблемы, требующие решения:

  • Сопротивление изменениям: Не все сотрудники сразу приняли новые процессы. Scrum казался избыточным, система заявок — бюрократией. Решение: терпеливое объяснение ценности, показ результатов на практике.
  • Инфраструктурные проблемы: Постоянные проблемы с VPN и интернетом создавали операционные риски. Работа в Bitrix прерывалась, сессии обрывались. Пришлось инвестировать в модернизацию сети.
  • Технический долг: Критический инцидент с модулем взаиморасчетов «съел» 2 недели работы команды. Это стало триггером для создания реестра доработок и планового рефакторинга.
  • Перегрузка Product Owner: Один из ключевых людей был перегружен задачами. Решение — делегирование части ответственности и привлечение внешних подрядчиков на рутинные операции.
  • Пробелы в компетенциях: Низкий уровень знаний команды в информационной безопасности, DevOps, современных практиках разработки. Запустили программу обучения с целью 3+ новых компетенции на сотрудника в квартал.
«Каждая проблема — это возможность улучшить систему. Главное — не прятать проблемы, а делать их видимыми и превращать в задачи для решения.»

💡 Ключевые уроки для руководителя IT-отдела

Что я понял за эти 7 месяцев:

  • Процессы важнее инструментов. Можно купить лучшую систему управления проектами, но без дисциплины команды она не даст результата. Scrum работает не из-за Jira или Bitrix, а из-за commitment’а команды.
  • Прозрачность = доверие. Когда бизнес видит, чем занят IT-отдел, жалоб становится меньше. Открытые бэклоги, публичные roadmap’ы, регулярные демо — это инвестиция в отношения.
  • Делегирование — не слабость, а сила. Первые месяцы я пытался быть «супергероем», решающим все проблемы. Это привело к выгоранию. Только передав ответственность команде, я смог заняться стратегией.
  • Измеряйте всё, что можно измерить. Velocity спринтов, время решения инцидентов, количество автоматизированных процессов — метрики позволяют управлять, а не «чувствовать».
  • Говорите на языке бизнеса. Не «мы внедрили микросервисную архитектуру», а «мы сократили время обработки заказов на 40%, что дает X рублей дополнительной выручки».
  • Инвестируйте в людей. Обучение, новые вызовы, рост компетенций — это то, что удерживает сильных специалистов. Мы запустили программу развития: DevOps для сисадмина, курсы бухгалтерии для Scrum Master’а.
  • Не всё нужно делать самим. Аутсорсинг 1-й линии поддержки, внешние эксперты по Power BI, подрядчики на узкие задачи — это нормально и эффективно.
  • Управление ожиданиями — часть работы. Объяснять стейкхолдерам, почему их задача не в топ-приоритетах, учить отказывать — это soft skill, который стоит развивать.

🔮 Что дальше: видение на 2026 год

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

Технологии

  • Завершение миграции на новый сервер 1С с двукратным ростом производительности
  • Полная автоматизация склада с терминалами сбора данных (ТСД)
  • Переход на Windows 11 и частичная миграция команды на Linux
  • Внедрение CI/CD для автоматизации развертывания
  • Развитие DevOps-практик (Docker, Kubernetes)

Процессы

  • Стабилизация velocity спринтов с отклонением не более ±10%
  • Полное покрытие процессов документацией (To-be модели)
  • База знаний, позволяющая решать 90%+ инцидентов без эскалации
  • Внедрение SLA для различных типов запросов

Команда

  • Трансформация в self-organizing team
  • Экспертиза каждого специалиста в 2-3 областях
  • Культура непрерывного обучения и экспериментов
  • Снижение зависимости от внешних подрядчиков за счет роста внутренних компетенций

Бизнес-партнерство

  • Позиционирование IT как драйвера роста, а не центра затрат
  • Измеримый бизнес-эффект от каждой инициативы
  • Проактивное предложение решений до того, как бизнес их запросит
  • Вовлечение бизнес-подразделений в планирование IT-roadmap

🎯 Главный вывод

Трансформация IT-отдела — это не про технологии. Это про людей, процессы и дисциплину. За 7 месяцев мы доказали, что даже средний IT-отдел может стать источником конкурентного преимущества для бизнеса, если последовательно инвестировать в правильные вещи: прозрачные процессы, развитие команды и измеримые результаты.

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

📚 Для руководителей IT: что можно применить прямо сейчас

Если вы руководите IT-отделом и узнали в описанных проблемах себя, вот несколько практических советов для старта трансформации:

  1. Запустите централизованную систему заявок — хоть в Trello, хоть в простом Kanban. Главное — сделать поток задач видимым.
  2. Введите регулярные стендапы — 15 минут каждое утро для синхронизации команды. Это бесплатно и работает сразу.
  3. Ограничьте WIP — не более 3 задач на человека одновременно. Лучше закончить меньше, но полностью, чем держать в работе десятки незавершенных задач.
  4. Начните измерять — время решения инцидентов, количество завершенных задач за неделю, удовлетворенность пользователей. Что измеряется — тем управляют.
  5. Инвестируйте в обучение команды — даже 1 час в неделю на саморазвитие даст результат через квартал.
  6. Установите регулярные встречи со стейкхолдерами — демонстрация результатов, сбор обратной связи, управление ожиданиями.
  7. Делегируйте рутину — если вы руководитель и решаете заявки на 1-й линии, вы не руководите. Найдите способ передать это.
  8. Создайте roadmap — простой план на квартал с 5-10 ключевыми инициативами. Публичный и понятный бизнесу.
Об авторе: IT-директор с опытом трансформации технических отделов в бизнес-партнеров. Специализация — процессы, автоматизация, управление изменениями.

Если у вас есть вопросы по внедрению подобных изменений в вашем IT-отделе — буду рад обсудить в комментариях.

Связанные материалы

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


 

The post Трансформация IT отдела first appeared on Portfolio.

]]> Работа с инцидентами в it отделе (Система тикетов) https://shknv.ru/rabota-s-incidentami-v-it-otdele-sistem/ Mon, 16 Dec 2024 19:16:21 +0000 https://shknv.ru/?p=212 Как организовать работу с инцидентами в IT-отделе: тикеты, статусы, ответственность и контроль выполнения.

The post Работа с инцидентами в it отделе (Система тикетов) first appeared on Portfolio.

]]> Работа с инцидентами в IT-отделе (Система тикетов)

Добрый день! Сегодня хотел бы рассказать вам, как создать работающую систему тикетов на базе Битрикс24. Это можно реализовать как в облачной версии, так и в коробочной. Причём в коробочной версии уже доступно почти готовое решение. Также я поделюсь, как такая система работает на двух разных проектах.

Основы системы тикетов

Вся система будет построена на смарт-процессах с использованием CRM-форм. Это позволяет структурировать заявки и настроить автоматизацию обработки.

Шаг 1: Определение типов тикетов

Pasted image 20241216215144.png

 

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

  • технические проблемы,
  • заявки для АХО,
  • инциденты, связанные с безопасностью.

 

 

Совет: Используйте правила показа полей в CRM Битрикс24, чтобы разграничить данные для разных типов заявок. Например, если клиент выбирает тип заявки «ИТ», отображаются поля, относящиеся только к ИТ.

Шаг 2: Создание полей для смарт-процесса

В смарт-процессе необходимо задать все необходимые поля. Рекомендуется использовать типы «список» или «радиокнопки» для удобства пользователей. Обязательно добавьте текстовые поля для описания проблемы или комментариев.

Примеры полей:

  • Тип заявки (список);
  • Описание проблемы (текст);
  • Важность (радиокнопки);
  • Дата возникновения инцидента (дата);
  • Контактный номер телефона (текст).
Шаг 3: Настройка CRM-формы

Создание формы проходит в несколько шагов:

  1. В настройках формы выберите привязку к сущности CRM и укажите созданный смарт-процесс.
  2. Добавьте необходимые поля и настройте их обязательность.
  3. Используйте правила показа полей. Например: если выбрано «Тип заявки: ИТ», отображаются поля для ввода технических данных.
  4. Добавьте поля для контактов: ФИО и номер телефона. Это позволит связаться с клиентом. Если номер телефона уже зарегистрирован в системе, можно настроить подстановку данных сотрудника через REST API.
    Pasted image 20241216215430.png
Шаг 4: Размещение формы

Форма должна быть доступной и легко заметной:

  • В облачной версии: разместите ссылку на форму в главном меню или на главной странице портала (в Вайбе).
  • В коробочной версии: добавьте кнопку в шапку сайта с помощью интеграторов. Это позволяет передавать параметр пользователя (например, ID) в скрытое поле формы. Для этого добавьте поле id_user и настройте его заполнение из адресной строки через %id_user%.
    Pasted image 20241216215550.png

Функциональность системы

На данном этапе у вас есть:

  • Смарт-процесс, в который поступают заявки;
  • CRM-форма, которую заполняют пользователи;
  • Кнопка для быстрого доступа к форме.
    Pasted image 20241216215820.png

Остаётся добавить автоматизацию.

Автоматизация обработки тикетов

  1. Настройка воронок: Создайте несколько воронок в смарт-процессе для разделения заявок разного типа.
  2. Уведомления: Настройте уведомления для ответственных сотрудников. Например, при создании тикета типа «ИТ» уведомляется ИТ-отдел.
  3. Назначение ответственных: Автоматически назначайте ответственного на основании типа заявки и её параметров (например, важности или отдела).
  4. Создание задач: Если система отчётности строится на задачах, настройте автоматическое создание задачи для обработки заявки. После завершения задачи тикет можно закрыть автоматически.

Пример автоматизации:

  • Пользователь заполняет форму, выбирая тип заявки «Техническая поддержка».
  • На основании выбора автоматически назначается сотрудник из ИТ-отдела.
  • Система отправляет уведомление ответственному сотруднику.
  • Создаётся задача в разделе «Задачи и Проекты» для учёта времени и этапов обработки инцидента.

Pasted image 20241216220032.png

Подготовка бизнес-процесса

Перед реализацией автоматизации опишите процесс в табличной форме (например, в Excel). Это поможет визуализировать все этапы и определить узкие места. Укажите:

  • точки входа (формы, порталы);
  • ответственных на каждом этапе;
  • варианты завершения процесса (решение тикета, перенос задачи).

Примеры форм.

простая форма инцидента
Снимок экрана 2024-12-16 174246.png

продвинутая форма на коробке
Pasted image 20241216214528.png

И самое главное, можно сделать небольшой процесс который будет считать время потрачено на решение инцидента и заполнять.
нам нужны 2 переменные времени и получаем из них номер недели(нужно если к примеру поставленн был в пятницу а завершили в понедельник)
Pasted image 20241216220258.png

и далее считаем по условию если переменная 2 больше переменно 1 то Время

=(({{Когда завершен > int}} - {{Когда создан > int}}) - 48 * 3600) / 3600

иначе

=({{Когда завершен > int}} - {{Когда создан > int}}) / 3600

приводим всё к читаемым единицам
{{=round({=Variable:time}, 2)}}

и записываем в поле в элементе и эту информацию уже можно будет анализировать .
Pasted image 20241216220803.png

Заключение

Создание системы тикетов на базе Битрикс24 — это эффективный способ управления инцидентами в IT-отделе. Смарт-процессы и CRM-формы позволяют настроить автоматизацию, сократить время на обработку заявок и улучшить контроль за их выполнением. Главное — заранее продумать структуру системы и автоматизацию каждого этапа.

Связанные материалы

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

The post Работа с инцидентами в it отделе (Система тикетов) first appeared on Portfolio.

]]>