Цифровую трансформацию начинают не с выбора ИТ-системы

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

Меня зовут Евгений Зубков. Я ИТ-консультант и руководитель проектов автоматизации и цифровой трансформации бизнеса. За годы работы мне приходилось иметь дело с компаниями из разных отраслей и на разных этапах развития.

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

Где и как искать причину проблем

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

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

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

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

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

Сначала был код, потом бизнес

В ИТ я пришел через разработку на 1С в 2017 году. Начинал стажером в торговой сети «Монетка», затем стал ведущим программистом и некоторое время замещал руководителя департамента разработки. Позже в ГК «ВМассиве» уже сам собирал отдел разработки и выстраивал работу команды.

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

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

Позже этот подход я применял в компаниях разных отраслей, работая как независимый консультант и руководитель проектов. Среди них были ПИК, ФСК, Asterus, компании из розницы, e-commerce, дистрибуции и производства.

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

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

Читайте также

Максим Березин: «Импортозамещение виртуализации стало необходимостью для снижения рисков»

Как меняется роль виртуализации в стратегиях компаний, какие решения на уровне виртуальной среды помогают сократить затраты на ИТ, как реализуется защита ИТ-периметра и какие инструменты помогают ускорить миграцию, IT-World рассказывает Максим БЕРЕЗИН, директор по развитию бизнеса Orion soft.

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

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

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

3300 задач и общие правила работы

Сейчас в SMSolutions моя работа сочетает нескольких ролей. Я веду проекты, общаюсь с заказчиками, занимаюсь бизнес-анализом и проектированием решений, а на финальном этапе контролирую качество внедрения. Постоянная команда у нас небольшая, всего три человека. Кроме меня, в ней два разработчика 1С. По мере необходимости подключаем внешних специалистов, и тогда над проектами регулярно работают уже шесть-семь человек. А для крупных внедрений привлекаем партнеров из сети франчайзи 1С.

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

Бывали периоды, когда одновременно шло до 10–15 проектов. Причем один мог находиться еще на этапе обследования, другой уже внедрялся, в третьем обучали пользователей, а четвертый переходил в сопровождение. При такой нагрузке уже невозможно помнить историю каждого решения. Через нашу систему управления проектами прошло больше 3300 задач. По мере роста этого массива у нас постепенно появились общие правила предпроектного обследования, постановки задач, проектирования, тестирования и сопровождения.

Этапы работы над проектом:

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

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

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

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

Откуда приходит информация? Что сотрудники переносят вручную? Где пользуются отдельными таблицами? Какие данные приходится уточнять? В какой момент одна система перестает понимать другую?

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

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

Читайте также

Что происходит с импортозамещением в российском ИТ

Еще недавно с источником спроса на российском ИТ-рынке все было понятно. Крупные компании срочно заменяли западные решения, при этом старались сохранить работу критичных систем и одновременно выполнить требования регуляторов.

Почему один отдел может быть эффективным, а компания нет

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

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

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

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

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

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

Выбор приоритетов

У любой компании список пожеланий длиннее бюджета и возможностей команды. Каждый отдел приходит со своими задачами, причем большинство из них вполне разумные. Как определить приоритет?

В таких случаях я задаю вопрос: «Что произойдет, если мы пока ничего не изменим?»

Если бизнес теряет заказы, есть риск потерять данные, происходят серьезные сбои или предстоят обязательные изменения с конкретным сроком, приоритет понятен.

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

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

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

Больше, чем автоматизация

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

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

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

Читайте также

Российский рынок Kubernetes-платформ

IT-World представляет обзор тенденций и основных игроков российского рынка платформ для управления Kubernetes-инфраструктурой. Рассмотрим управление кластерами, безопасность, мониторинг, обновления, интеграции и поддержку корпоративных сценариев.

Во втором случае меняется уже не одна операция. По-другому строится сама услуга, отношения с клиентом, планирование загрузки инженеров и ответственность компании.

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

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

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

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

Временное = постоянное

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

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

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

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

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

Многоэтапное тестирование

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

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

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

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

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

Читайте также

Олег Гомазков: «Если пожара не было пять лет, это не значит, что можно уволить пожарных»

Когда денег не хватает на всё, ИБ часто перестает быть «особой» статьей бюджета. Ее приходится сравнивать с другими инвестициями и отвечать на вполне финансовые вопросы.

Ремонт или замена системы?

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

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

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

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

Цифры после запуска

Я стараюсь обсуждать ожидаемый результат еще до начала разработки и заранее определять, что именно должно измениться.

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

Таблица 1. Результаты проектов по ключевым показателям:

Однако напрямую переносить эти показатели на любой новый проект некорректно. У компаний разная исходная ситуация.

Мне важнее сам принцип. После запуска нужно суметь ответить не на вопрос «Система работает?», а на другой: «Что изменилось в бизнесе?»

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

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

Что меняется с появлением ИИ

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

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

Читайте также

ИИ-агенты в продуктиве: решает не количество ускорителей, а архитектура вокруг них

Компании перешли от чат-ботов и ИИ-ассистентов к агентным системам, которые самостоятельно выполняют многослойные и более сложные задачи. На этом этапе обнаруживается, что инфраструктура, на которой успешно прошел пилот, не выдерживает промышленной нагрузки. Почему так происходит и что стоит заложить в архитектуру заранее, IT-World рассказал Антон Юдин, руководитель направления ИИ-инфраструктуры Скала^р (Группа Rubytech).

ИИ применяется и в клиентских проектах.

Для логистической компании мы разработали AI-ассистента, который на основании поступивших заказов определяет необходимое количество автомобилей, анализирует объем перевозок и строит маршруты доставки.

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

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

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

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

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

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

Иногда это будет ERP. Иногда интеграция существующих систем. Иногда ИИ.

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

И в такой ситуации я тоже считаю, что свою работу сделал.