Лаборатория цифровых решений

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

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

Ставка сделана на другое: 🔴создаётся консорциум, который собирает требования от реального бизнеса (металлургия, нефть и газ, химия, транспорт и др.); 🔴уже сформировано >1,3 тыс. требований к российским ERP — не к «мифическому аналогу SAP», а к экосистеме решений разных вендоров; 🔴идея одна: не лепить монстра «с нуля», а доращивать уже существующие продукты под реальные нужды отраслей. Для рынка ERP и проектных команд это означает простую вещь: будущее — за архитектурой и интеграцией, а не за одной «волшебной суперсистемой»...

Говорят, цифровая трансформация — это про новые программы, облачные сервисы, искусственный интеллект. На деле всё иначе. Да, технологии важны. Но они лишь инструмент. Главное — как мы ими пользуемся, как они меняют наше мышление, наши решения, наши отношения в команде. Раньше управленец знал всё. Он принимал решения, потому что имел доступ к информации, которой не было у других. Сегодня любой сотрудник может за минуту найти данные, которые раньше собирались неделями. Это не просто меняет баланс власти — это ломает старую модель управления...

Каждую неделю вы получаете отчет о работе: цифры, графики, четкие показатели. Вы знаете, что делать, потому что видите, где прибыль, а где провал. А теперь представьте, что этот отчет внезапно исчезает. На месяц. Потом на полгода. Потом на полтора года. Вы продолжаете работать, но уже вслепую. Именно это произошло с Woolworth’s Australia, когда компания решила обновить свою старую систему, которой пользовалась тридцать лет. Казалось бы, что может пойти не так? Оказалось, что почти всё. Технически сбой объяснялся просто: изменили способ сбора информации, и отчеты перестали генерироваться...

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

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

Если честно, я давно перестал верить в «универсальных специалистов». Тех, кто «всё умеет» и «сразу всё поймёт». В реальности таких почти нет. А если и есть — они редко работают в проектах, где нужно не просто что-то настроить, а полностью перестроить систему управления бизнесом. Особенно когда речь идёт о внедрении 1С:ERP. Я видел много проектов. Не просто читал отчёты участвовал, наблюдал, анализировал. И каждый раз, когда что-то шло не так, причина была одна: команда заказчика думала, что можно сэкономить на людях...

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

ERP не спасает плохие процессы. Но может помочь их исправить Планировать трансформацию бизнеса — всё равно что собирать пазл, где половина деталей ещё не напечатана. Многие до сих пор верят, что сначала нужно чётко прописать стратегию, потом перестроить процессы, затем подогнать финансы, и только в самом конце запускать ERP. На бумаге это выглядит логично. В жизни — не работает. Реальность устроена иначе. Стратегия без живых процессов — просто красивый текст. Оргструктура, не связанная с тем, как на самом деле работают люди, быстро превращается в бюрократическую оболочку...

API в 1С: как платформа говорит с миром Иногда кажется, что программы живут в своём собственном мире. Каждая — со своими правилами, логикой и данными. Но рано или поздно возникает вопрос: а как сделать так, чтобы они начали «разговаривать» между собой? Чтобы 1С могла передавать данные в CRM-систему, обмениваться информацией с интернет-магазином или получать статусы от складской системы? Вот тут и появляется API. Это не какая-то магия. Просто инструмент, который позволяет разным системам понимать друг друга...

“Поставьте как в том проекте” — и другие ошибки тиражирования решений Почему даже похожие компании требуют разного подхода. Где заканчивается шаблон, и начинается архитектура. На старте проекта это звучит часто: А давайте просто сделаем как в том проекте. Там же всё нормально работало. Звучит разумно. Проверенное решение, экономия времени, «не изобретать велосипед». Но по факту в 9 из 10 случаев такая просьба оборачивается проблемой. Почему нельзя просто «перенести» архитектуру: ~ Процессы даже в похожих компаниях устроены по-разному...