
Когда говорят об информационных процессах, многие коллеги сразу думают о софте — SAP, 1С, BI-системах. Это ключевая ошибка. На деле, это в первую очередь про то, как данные превращаются в решение на совещании у директора, и почему отчёт из цеха иногда доходит до планового отдела через три дня, когда сроки уже горят. Я это понял не из книг, а когда пытался внедрить систему сбора данных по OEE на одном из заводов, и столкнулся с тем, что мастер участка вёл учёт в тетрадке, а потом его помощник вручную сводил это в Excel. Информационный процесс был, но его скорость и качество сводили на нет всю цифровизацию.
Взять, к примеру, типичную задачу — управление запасами сырья. В теории: датчики на складе, интеграция с ERP, автоматические заказы. В реальности: кладовщик фиксирует приход/расход в 1С, но не всегда сразу. Начальник производства видит остатки в системе, но не доверяет им полностью, поэтому звонит кладовщику. Тот сверяется со своими бумажными записями. Возникает параллельный, неформализованный контур обмена данными. Это и есть живой, но проблемный информационный процесс.
Мы с командой из ООО Хэнань Цзюйхэ Текнолоджи как-то разбирали подобный кейс для клиента из пищевой отрасли. Задача была не в том, чтобы поставить новые сканеры, а в том, чтобы регламентировать и упростить действия кладовщика, увязав их с его же мотивацией. Информация должна была стать не дополнительной работой, а естественным побочным продуктом его основных действий. Сделали мобильное приложение с максимально простым интерфейсом — фактически три кнопки. Но главное — изменили процесс приёмки, сделав сканирование штрихкода обязательным и единственным способом оприходования. Шум в виде звонков и уточнений сократился процентов на 70.
Этот опыт показал, что проектируя системы управления, часто упираешься в человеческий фактор и устоявшиеся, часто иррациональные, цепочки доверия. Технология — лишь инструмент, который либо встраивается в эти цепочки, либо ломает их, вызывая сопротивление. Ломать — дорого и болезненно. Гораздо эффективнее — понять логику этого неформального обмена и цифровизировать именно её, а не абстрактный ?идеальный процесс? из учебника.
Следующий пласт проблем — стыки. Отдел продаж работает в CRM, производство — в MES, финансы — в бухгалтерском модуле. Каждый модуль живёт в своём информационном потоке. А решение, скажем, об увеличении партии выпуска, требует данных из всех трёх. Вот здесь и начинается ад в виде выгрузок в Excel, ручных сводок и неизбежных ошибок.
Один из наших проектов на hnjhkjjt.ru как раз касался создания единой операционной панели для руководства сетью розничных магазинов. Клиент жаловался, что не понимает реальной маржинальности по товарным группам, потому что данные по закупкам, продажам и логистическим издержкам были в разных, не связанных между собой системах. Мы не стали строить мега-систему с нуля. Вместо этого создали слой интеграции (middleware), который в near real-time стягивал ключевые показатели из этих разнородных источников в единое хранилище. Важно было не просто свести данные, а наладить процесс их согласования — чтобы финансовый контролёр и коммерческий директор оперировали одними и теми же цифрами, с одной и той же логикой расчёта.
Это была не столько техническая, сколько организационная работа. Пришлось провести серию рабочих групп, где представители отделов впервые за долгое время сели и по пунктам обсудили, что такое ?себестоимость товара на полке? для каждого из них. Оказалось, что definitions разные. Самый сложный этап — не написание кода, а выработка единых правил игры, общего семантического поля. Без этого любой, даже самый дорогой софт, бесполезен.
Классическая проблема информационных процессов в системах управления — разрыв между оперативными данными и стратегическими отчётами. Руководство получает красивые дашборды, но данные в них — двухнедельной давности. Ценность такой информации для оперативного управления близка к нулю. Она годится только для кабинетного анализа постфактум.
На одном из металлургических комбинатов мы видели попытку внедрить систему предиктивного обслуживания оборудования. Сенсоры ставили, данные собирали. Но процесс их анализа был выстроен так: данные неделю копились, потом инженер по надежности раз в неделю формировал отчёт для главного механика. Тот, в свою очередь, выносил вопросы на планерку. К тому моменту, когда принималось решение о внеплановой остановке для ремонта, поломка часто уже происходила. Процесс сбора информации был, а процесса её оперативного использования — не было.
Пришлось перестраивать. Мы помогли выстроить процесс, где ключевые алерты (например, рост вибрации выше порогового значения) в автоматическом режиме, минуя все бюрократические ступени, приходили напрямую на планшет сменному инженеру и в мобильное приложение начальнику цеха. Параллельно, конечно, данные шли в общую систему для аналитики. Но главное — изменилась сама логика: информация вела к немедленному действию. Это и есть цель — замкнуть информационный контур управления, сократив время между регистрацией данных и реакцией на них.
Вот здесь как раз лежит фокус деятельности таких компаний, как наша, ООО Хэнань Цзюйхэ Текнолоджи. Мы позиционируем себя как поставщик услуг цифровой трансформации, и для нас это именно трансформация информационных процессов. Клиент часто приходит с запросом ?хочу искусственный интеллект для прогноза продаж?. А в ходе аудита выясняется, что у него нет отлаженного процесса ежедневного сбора актуальных данных о продажах с точек — менеджеры отчитываются раз в неделю по электронной почте в произвольной форме.
Бессмысленно ставить сложные алгоритмы на гнилой фундамент. Наша работа часто начинается с, казалось бы, рутинных вещей: помогаем прописать регламент сбора данных, разработать простые формы, автоматизировать их заполнение, мотивировать персонал на соблюдение этих правил. Это не так технологически сексуально, как нейросети, но без этого все последующие навороты не работают. Цифровизация — это сначала дисциплина данных, а уже потом сложные аналитические надстройки.
Например, для дистрибьюторской компании мы внедряли систему управления маршрутами доставки. Магия была не в самом алгоритме построения маршрута, а в том, что мы интегрировали его с мобильным приложением водителя, системой учёта остатков на складе и CRM. В результате заказ на отгрузку, сформированный менеджером, автоматически превращался в задание для склада и оптимальный маршрут для водителя, а информация о выполненной доставке в реальном времени поступала обратно в CRM для выставления счёта. Мы перепрошили цепочку из четырёх-пяти разрозненных процессов в один сквозной и автоматизированный.
В итоге, мой главный вывод за годы работы: эффективный информационный процесс в системе управления — это тот, который работает без постоянного вмешательства руководителя. Он прописан, понятен исполнителям, технологически поддержан и, что важно, даёт им пользу. Кладовщику проще отсканировать штрихкод, чем вести тетрадь. Менеджеру по продажам удобнее обновить статус в CRM с телефона, чем потом мучительно вспоминать и сводить отчёт.
Задача специалиста — увидеть эти живые, часто неформальные потоки информации внутри предприятия, понять их логику и ?оцифровать? их с минимальным трением. Иногда это означает отказ от сложных решений в пользу простых, но работающих здесь и сейчас. Как в том случае с тремя кнопками для кладовщика. Идеальных процессов не существует, есть адекватные конкретным людям и конкретным задачам. И именно в их настройке, а не в продаже ?волшебных? коробок с софтом, и заключается реальная ценность цифровой трансформации, которой мы в ООО Хэнань Цзюйхэ Текнолоджи и занимаемся.
Поэтому, возвращаясь к началу, скажу: когда в следующий раз будете думать об информационных процессах, посмотрите не на серверы, а на людей. На то, как они сейчас получают данные, чтобы принять решение. И спросите себя: что можно убрать из этой цепочки, чтобы решение стало быстрее и точнее? Ответ на этот вопрос и будет первым шагом к реальным улучшениям.