Мы теряем контроль над сложной ERP. Что делать?

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

Глава 5. Что делать со сложной ERP: почему это поле обязательно

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

Проблема начинается, когда пользователь задаёт следующий вопрос: «Хорошо. А почему оно обязательное?»

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

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

Звёздочка показывает требование, но скрывает причину

Представим обычную ситуацию. В документе существует поле «Направление деятельности». Пользователь оформляет операцию и система требует его заполнить. Для самого пользователя это может выглядеть странно: товар известен, контрагент известен, подразделение указано, сумма рассчитана. Зачем ещё одно значение, без которого нельзя закончить документ?

Если спросить нескольких участников процесса, легко получить несколько разных объяснений. Один сотрудник скажет, что поле необходимо бухгалтерии. Другой вспомнит, что без него неправильно формируется какой-то отчёт. Третий уверен, что это обычное требование. Четвёртый вообще не знает причины, но много лет выбирает одно и то же значение, потому что так показали при обучении.

При этом все они могут добросовестно работать в системе.

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

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

Для качественной ERP это принципиально разные ситуации.

Одинаковая звёздочка может означать совершенно разные вещи

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

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

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

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

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

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

Почему ответ «так требует ERP» почти всегда недостаточен

Фраза «это требует ERP» удобна тем, что завершает разговор. Она переводит требование из области обсуждаемых решений в область почти физических законов. Пользователь может быть недоволен, но спорить вроде бы не с кем: программа устроена именно так.

Для сложной ERP такой ответ опасен.

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

Иначе техническое поведение подмеяет объяснение.

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

Но если причина не сохранилась, звёздочка продолжает жить собственной жизнью.

Четыре причины одной обязательности

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

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

Это разделение важно не ради классификации как таковой. Оно определяет, что можно делать с полем дальше.

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

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

Самый важный вопрос — когда значение становится известным

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

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

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

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

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

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