«Просто сделайте ровно так, как я нарисовал», «перенесите один в один из старой базы» и финальное «мы же вам деньги платим, почему вы нас не остановили?» – этот сценарий знаком каждому архитектору и аналитику. Заказчик приходит с готовым техническим решением, команда берет его в работу, а через полгода проект тонет в бесконечных доработках, костылях и взаимных претензиях.
В 1С я работаю больше 16 лет. За это время я вывел для себя главное правило: клиент всегда прав в том, что у него есть проблема, но далеко не всегда прав в том, как ее нужно решать.
Чем сложнее бизнес-задача, тем сильнее соблазн либо механически скопировать старую систему, либо выстроить вокруг нее громоздкую архитектурную конструкцию. А на практике ценность чаще всего появляется там, где удается найти простое и понятное решение.
Но к этому пониманию мы пришли через собственный болезненный опыт.
Как мы честно сделали «по ТЗ» и создали монстра
Несколько лет назад мы переводили крупного дистрибьютора с исторической самописной 1С на 1С:ERP. Запрос бизнеса звучал стандартно: настроить контроль кредитных лимитов при отгрузке. На словах все выглядело безобидно – в старой программе механизм существовал годами, требовалось лишь перенести логику.
Когда мы погрузились в детали, перед нами открылся целый зоопарк правил:
-
лимит на саму отгрузку и лимит на резервирование
-
лимиты подразделения, направления и персональные лимиты конкретных руководителей
-
абсолютные и относительные пороги с динамическим пересчетом «на лету» прямо в момент проведения заказа, пока менеджер висит на телефоне с покупателем
Мы подошли к задаче с профессиональным азартом: раз просят – сделаем. И совершили фундаментальную ошибку: автоматизировали не бизнес-потребность, а нагромождение костылей из исторической системы.
Формально проект сдали. Код работал, проверки и условия ТЗ (по согласованным кейсам) соблюдались. Но реальный бизнес встал.
Отгрузки хаотично блокировались: один заказ система пропускала, соседний – заворачивала. Менеджеры не понимали причин отказа, руководители путались в собственных регламентах, а служба поддержки круглосуточно «проталкивала» документы вручную, чтобы клиенты не ушли к конкурентам.
Мы попытались зайти на вторую итерацию, чтобы все исправить, и моментально утонули в терминологических спорах. Все участники процесса произносили слово «лимит», но каждый вкладывал в него собственный смысл.
Отказ от механизмов в пользу сценариев
Тогда мы остановились и предложили заказчику обнулить договоренности: забыть, как механизм был устроен раньше, и описать реальные управленческие ситуации, в которых людям вообще требуется принимать решения.
Мы начали декомпозировать этот ком требований на независимые сценарии. Первое же открытие отрезвило всех: для половины существовавших правил мы просто не смогли найти владельца процесса. Мы согласовали это с собственниками бизнеса и безболезненно вычеркнули лишнее.
В сухом остатке от огромного клубка правил осталось всего три понятных сценария:
-
Отгрузка по предоплате без поступивших денег. Менеджеру нужно срочно отгрузить товар, пока платежка еще идет через банк – сделали изолированное рабочее место, где ответственный руководитель ставит электронную визу. Система проверяет его полномочия и пропускает заказ, не затрагивая остальные механизмы
-
Временное увеличение суммы отгрузки в долг. Клиенту разово требуется расширить объем поставок на несколько дней – появилась возможность точечно разрешать отгрузку с конкретным сроком действия прямо в договоре контрагента
-
Отгрузка при наличии просроченной задолженности. Ситуация, когда у клиента есть просроченный долг, но партнерские отношения требуют продолжить поставки – для этого реализовали отдельный явный регламент согласования исключения
Из системы полностью ушло размытое понятие «лимит», уступив место прозрачной кредитной линии по договору. Вместо черного ящика со скрытой логикой бизнес получил три простых, контролируемых инструмента. Мы запустили прототип, и процессы заработали штатно.
Четыре шага к простому решению
Из этого кейса у нас сформировался прикладной фреймворк поиска решений. В его основе – синтез проверенных инженерных практик: ТРИЗ, Jobs to Be Done, Lean Production, системного мышления и Domain-Driven Design (DDD).
Шаг 1. Разделяйте задачу на части
Сложную комплексную проблему невозможно решить целиком. Ее нужно раздробить на независимые составляющие и проследить связи между ними. В ТРИЗ это формулируется как принцип дробления: разделение системы на автономные части повышает ее гибкость и управляемость. Как только процесс разложен на отдельные ветки, сразу становятся видны реальные точки принятия решений.
Шаг 2. Ищите истинную потребность
Здесь надежно работает техника «5 почему». Мы докапываемся до первопричины запроса, применяя логику Jobs to Be Done (JTBD) – выясняем, на какую именно «работу» бизнес «нанимает» ту или иную функцию.
Диалог часто выглядит так:
-
Нам нужен новый отчет
-
Зачем?
-
Чтобы контролировать вот эту колонку показателей
-
Зачем ее контролировать?
-
Потому что менеджеры на этом шаге постоянно ошибаются
В этот момент выясняется, что отчет вообще не нужен – нужно скорректировать сам процесс так, чтобы совершить ошибку на том этапе было физически невозможно.
Главным ориентиром в этом поиске служат показатели эффективности (KPI). Мы принципиально не обсуждаем с клиентом кнопки и галочки, а говорим на языке оцифрованного результата:
-
мы сокращаем время обработки заказа с суток до двух часов?
-
мы снижаем просроченную дебиторку на 20%?
-
или увеличиваем оборачиваемость склада?
Шаг 3. Отсекайте все лишнее
Зафиксированный целевой KPI позволяет отсечь любые требования, которые прямо сейчас на него не влияют. Здесь работают принципы устранения потерь (Muda) из Lean и концепция Идеального Конечного Результата (ИКР) из ТРИЗ.
Идеал в ИТ – когда система сама выполняет требуемую функцию без участия человека. Если сверять каждое пожелание с этим идеалом, становится очевидно, какие сущности и отчеты бизнес пытается перенести в 1С просто по инерции.
Шаг 4. Начинайте с типового функционала
Архитектор 1С всегда отталкивается от возможностей и ограничений типового тиражного решения. Если типовой функционал закрывает целевые KPI – мы берем его без изменений.
Кастомизация оправдана только тогда, когда типовой механизм объективно не позволяет достичь бизнес-цели. Доработка должна рождаться не из желания аналитика, а из доказанной экономической необходимости.
Три примера из практики
Кейс 1. Импортные закупки: разделение хаоса и порядка (ТРИЗ)
Производственная компания собирает продукцию из зарубежных компонентов. При переходе на 1С:ERP руководство захотело видеть в системе абсолютно весь сквозной процесс: от зарождения идеи товара, эскизов дизайна и маркетинговых гипотез до финальной контейнерной поставки из Китая.
На этапе моделирования мы наткнулись на классическое системное противоречие. Первая половина процесса – это чистое творчество, генерация идей, перебор вариантов и постоянные правки. Бизнес стремился завести эти наброски в ERP ради полного контроля. Однако учетная система требует строгих справочников, структуры и регламентов, а попытка оцифровать творческий беспорядок в единой базе неизбежно приводит к ее замусориванию.
Здесь отлично сработал тризовский принцип вынесения. Мы разделили процесс на два контура: исследовательскую работу, творческий поиск и черновые расчеты оставили за скобками в привычном Excel, а в 1С:ERP завели только четкий, структурированный этап закупки.
Клиент легко согласился с этим решением, как только мы обратились к его ключевым показателям эффективности. Главными целями проекта были сокращение времени цикла закупки и минимизация ошибок ручного ввода. Перенос сырых дизайнерских черновиков в ERP породил бы большой объем ручных правок и только затянул бы процесс. В результате заказчик получил прозрачный контур закупок без раздувания стоимости владения системой (TCO).
Кейс 2. «Отряды»: разграничение доступа без тяжелого RLS (JTBD)
В крупной торговой компании работало около 500 менеджеров по продажам. Чтобы мотивировать сотрудников и растить будущих руководителей, бизнес внедрил внутреннюю неформальную структуру – «отряды». В официальном штатном расписании этих групп не было, но заказчик пришел с категоричным требованием: «Каждый отряд должен видеть только своих контрагентов».
Сначала мы пошли стандартным техническим путем: включили типовой механизм RLS, связали группы доступа партнеров с группами пользователей и сдали работу. А дальше началась реальная жизнь. Менеджеры переходили от одного куратора к другому, перетягивая за собой клиентов. С крупными сетевыми покупателями одновременно работали сотрудники из разных групп. В итоге система прав превратилась в неуправляемую паутину: база данных начала ощутимо тормозить, а служба поддержки каждое утро вручную восстанавливала запутанные доступы.
Тогда мы обратились к методологии JTBD и задали ключевой вопрос: какую реальную проблему бизнес пытается решить ограничением прав? Оказалось, цель была вовсе не в том, чтобы физически скрыть сам объект «клиент», а чтобы защитить чувствительную коммерческую информацию.
Как только истинная потребность прояснилась, мы отказались от RLS. Вместо него сделали точечную доработку интерфейса: одни пользователи видели полную карточку клиента, а другие – урезанную версию с закрытыми контактными данными. Скорость работы системы вернулась в норму, риски утечки были надежно перекрыты, а ежедневный ад администрирования прав исчез.
Кейс 3. «Лифты»: единый язык вместо подсистемы производства (DDD)
Компания занимается монтажом и сервисным обслуживанием лифтового оборудования и переходит с SAP на 1С:ERP. Запрос бизнеса звучал привычно для их уклада: «Мы выполняем работы по техническому обслуживанию, собираем затраты, делаем выпуск и выставляем акты».
Для специалиста по 1С формулировка «собирать затраты и выпускать работы» звучит как прямой призыв включить тяжелый производственный контур. В 1С:ERP это тянет за собой спецификации, распределение номенклатурных затрат на 20-й счет, выпуски и так далее. На этапе пресейла мы именно так все смоделировали и показали. Клиент посмотрел на схему и вздохнул: «Выглядит сложно, но раз в 1С так принято – давайте внедрять».
Однако на этапе проектирования мы начали синхронизировать термины и смыслы. Здесь нас выручил принцип Единого языка из Domain-Driven Design. Мы выяснили, что слово «работа» пришло исключительно из терминов SAP, а по экономической сути компания оказывает регулярную абонентскую услугу.
Услугу не нужно «выпускать» через производственные цепочки. Мы полностью убрали производственный блок из проекта. Вместо него настроили компактный интерфейс биллинга: он забирает данные о фактических выездах мастеров из внешнего сервиса, автоматически формирует реализации услуг и рассылает акты заказчикам. Мы сэкономили клиенту несколько месяцев сложной разработки, избавив бизнес и учет от избыточных сущностей.
Чек-лист для следующей сложной задачи
Когда заказчик в следующий раз придет с готовым решением и фразой «просто сделайте так», не торопитесь «открывать конфигуратор». Пройдитесь по пяти вопросам:
-
Какой KPI мы улучшаем? Переведите абстрактные пожелания в оцифрованные бизнес-метрики
-
В чем истинная потребность? Задайте серию вопросов «зачем?», чтобы отделить реальную проблему от привычного шаблона решения
-
В чем системное противоречие? Определите конфликт между ожиданиями бизнеса и ограничениями архитектуры
-
Как выглядит Идеальный Результат? Представьте, как процесс функционировал бы сам по себе, без участия пользователей
-
Где граница типового функционала? Соберите базовый сценарий на стандартных возможностях системы и кастомизируйте только то, что напрямую влияет на целевую метрику
Не бойтесь задавать на встречах наивные вопросы: «А зачем нам этот отчет?», «Что сломается, если мы уберем это согласование?». Гораздо опаснее показаться умным и построить сложную, дорогую систему, которой никто не сможет пользоваться.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
