Когда впервые задумываешься о том, почему одни системы работают, а другие превращаются в неповоротливые конструкции, которые невозможно поддерживать и невозможно развить, открывается удивительный мир. Парадокс заключается в следующем: проектирование автоматизированной системы по своей сути является упрощением бизнес-процессов, однако далеко не каждое упрощение сохраняет важные свойства реальных операций компании. Искусство упрощения в контексте информационных систем — это не отбрасывание лишнего, а выделение главного. Звучит банально, но именно эта банальность содержит в себе целый мир нюансов и подводных камней, о которых не говорят в учебниках по системному анализу.
Главная ошибка упрощения при проектировании систем
Проблема упрощения в проектировании автоматизированных систем заключается в том, что часто непонятно, что именно упрощается. Берётся сложный бизнес-процесс — будь то управление цепочками поставок, документооборот между подразделениями или взаимодействие с клиентами — и начинают отсекаться куски, потому что они кажутся несущественными. Потом приходит удивление: система работает не так, как ожидалось, пользователи саботируют новые процессы, а руководство не понимает, почему автоматизация не принесла обещанных результатов. Дело не в том, что система плоха сама по себе. Дело в том, что отсеклось что-то важное, хотя это не осознавалось. Было решено, что вот эта переменная не влияет на результат, но она влияет. Было решено, что границы модуля проходят здесь, а на самом деле они проходят совсем в другом месте.
Неправильный выбор границ между модулями — это самая серьёзная ошибка в проектировании систем. Когда принимается решение о том, что входит в компетенцию модуля логистики, а что должно обрабатываться модулем финансов, совершается самое важное упрощение. От этого выбора зависит абсолютно всё: и удобство работы пользователей, и затраты на интеграцию, и возможность дальнейшего развития системы.
Пример выбора границ между подсистемами
Рассмотрим типичную ситуацию: нужно спроектировать модуль управления закупками для производственного предприятия. Можно построить модель, учитывающую только процесс формирования заказа и его отправку поставщику. Тогда получается относительно простой модуль, который решает одну узкую задачу. А можно расширить границы системы и включить в неё планирование потребностей на основе производственной программы, контроль сроков поставки сырья, управление взаиморасчётами с поставщиками, анализ эффективности закупок. Тогда выясняется, что закупки — это не изолированный процесс, а часть сложной системы, которая тесно связана с производственным планированием, складским учётом и финансовым планированием. Модуль стал сложнее, но он стал честнее. И, что важно, он стал полезнее. Появляется понимание не только того, что происходит в отделе закупок, но и почему это происходит именно так, а не иначе.
Принцип релевантной сложности в проектировании
Существует принцип, который можно назвать принципом релевантной сложности. Он говорит о том, что сложность модели должна соответствовать сложности того бизнес-процесса, который автоматизируется. Когда предпринимается попытка описать работу отдела продаж с помощью простых таблиц и статусов, теряется важная информация о клиентском опыте, особенностях работы с разными типами клиентов, сезонных колебаниях и особенностях переговорных процессов. Если не учитывать хотя бы часть этих вещей, модуль становится бесполезным инструментом, который формально выполняет свою функцию, но не помогает бизнесу развиваться.
Но здесь возникает другая проблема. Если учитывать абсолютно всё, подсистема становится такой же сложной, как та область деятельности, которую он автоматизирует. Тогда возникает вопрос: зачем тогда автоматизировать? Цель упрощения — не воспроизвести бизнес-процесс один к одному. Цель упрощения — выделить те связи и зависимости, которые действительно определяют эффективность работы в данном контексте. Это как с хорошим интерфейсом. Он не показывает пользователю каждое поле базы данных. Но он показывает то, что нужно для выполнения конкретной задачи. Это не искажение реальности — это упрощение, сохраняющее нужные свойства.
Если вам близка тема «как упростить сложное, не превратив всё в примитив», заглядывайте в наш канал TechITPM — там регулярно разбираем, как моделировать процессы, архитектуру и изменения так, чтобы ими реально можно было управлять.
И как раз скоро стартует курс «Управление изменениями: как успешно внедрять новые системы» — про то, как переводить сложные трансформации в понятные шаги для людей, процессов и ERP-ландшафта. Подробнее на сайте.
Скульптурный подход к проектированию систем
Хороший образ для понимания упрощения в автоматизированных системах— это скульптура. Когда скульптор берёт глыбу мрамора и создаёт из неё статую, он не искажает камень. Он убирает всё лишнее, чтобы проявилось то, что было внутри. Проектирование, например, ERP-системы — это примерно то же самое. Берётся бизнес-процесс во всей его сложности и постепенно убирается то, что не влияет на достижение целей автоматизации. Но нужно знать, что убирается. Нужно понимать, почему это можно убрать. Иначе вместо работающего инструмента получается бесформенная конструкция, которая пытается быть всем и не является ничем.
Опасность слишком быстрого упрощения
Одна из самых распространённых ошибок в IT проектах — упрощать слишком быстро. Команда проекта смотрит на сложный бизнес-процесс, видит в нём хаос и думает: давайте уберём половину промежуточных согласований, посмотрим, что получится. Иногда это работает. Но чаще — нет. Потому что заранее неизвестно, какие именно согласования обеспечивают качество принимаемых решений. Существуют примеры проектов, в которых были построены красивые и элегантные системы управления складом, отброшены «незначительные» процедуры инвентаризации, а потом эти системы обвиняли в том, что они не видят реальные остатки товаров. Модели были элегантными, математически безупречными и абсолютно бесполезными в момент, когда нужно было понять, куда делись материальные ценности.
Итеративный путь к правильному упрощению
Как же понять, что можно упрощать, а что нельзя? Ответ простой, но неочевидный. Нужно смотреть на то, что происходит на границах. Там, где бизнес-процесс соприкасается с другими процессами, там часто скрываются самые важные связи. Именно через эти границы поступает информация, именно там чаще всего происходят неожиданные вещи, которые ломают красивую модель.
Ещё один важный принцип: упрощение должно быть итеративным. Нельзя сразу построить идеальную систему. Нужно построить первую версию, посмотреть, где она ошибается, понять почему, добавить упущенное и повторить. Это медленно. Это дорого. Это не даёт ощущения гениального озарения. Но это работает. Постепенное усложнение через обратную связь — единственный надёжный способ построить систему, которая не подведёт в важный момент.
Модель и её практическое применение
Модели данных и бизнес-логика имеют свойство становиться самоцелью. Команда проекта разрабатывает сложную модель данных, влюбляется в неё, начинает защищать её от потребностей бизнеса вместо того, чтобы использовать её для решения реальных задач. Это психологическая ловушка. Модель данных — это инструмент, не более того. Хороший инструмент тот, который помогает, а не тот, который красиво выглядит или которым приятно пользоваться. Если модель не даёт возможности формировать нужные отчёты, не помогает ускорить принятие решений, не объясняет того, что раньше было непонятно, значит, она плохая, независимо от элегантности её структуры или строгости её нормализации.
Критерий достаточного упрощения
Главный критерий «достаточного» упрощения — ответ на вопрос: помогает ли эта система работать? Не хранить данные с абсолютной полнотой — это невозможно — а работать более осознанно, более эффективно, более честно по отношению к реальным потребностям бизнеса? Если да, то упрощение удалось. Если нет, то было упрощено слишком много, или упрощено не то, или упрощено в принципе неправильно.
Упрощение без искажения сути бизнес-процесса — это навык, которому можно научиться. Медленно, методом проб и ошибок, раз за разом наступая на одни и те же грабли. Но каждый раз понимая чуть больше. Каждый раз приближаясь к тому, чтобы видеть не только сложность бизнеса, но и то, что за ней скрывается. Самое интересное, что конечной точки не существует. Всегда можно упростить лучше. Всегда можно увидеть глубже. Всегда можно понять больше. И в этом, наверное, и есть смысл проектирования автоматизированных систем — не в том, чтобы найти окончательное решение, а в том, чтобы задавать всё более точные вопросы бизнесу и находить на них честные ответы, которые ложатся в основу работающих систем.
Понравилась статья?
Ставьте «палец вверх» и подписывайтесь на канал, если статья оказалась полезной.
Больше интересных тем — на нашем ✈️ Telegram-канале.
Подробнее о наших курсах — на сайте