Как проектируют корпоративную систему с нуля

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

Заявки обрабатываются в одном сервисе.

Часть информации передаётся через API, часть — файлами, а что-то сотрудники продолжают переносить вручную.

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

Именно тогда возникает задача разработки корпоративной системы с нуля.

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

Корпоративная система начинается не с интерфейса

Одна из самых дорогих ошибок — начинать проект с экранов.

Компания показывает разработчикам несколько примеров:

«Вот примерно такое окно нам нужно».

После этого появляются кнопки, таблицы и карточки.

Но через несколько месяцев выясняется, что:

Поэтому сначала проектируют не интерфейс.

Сначала проектируют саму систему и её место в бизнес-процессе.

Упрощённо путь выглядит так:

Именно первые этапы определяют, насколько сложными окажутся последующие.

Что уже существует в компании

Перед проектированием новой системы нужно составить карту текущей инфраструктуры.

Здесь важно выяснить не только названия программ.

Нужно понять:

Без этой картины новая система рискует просто добавить ещё один слой сложности.

Сначала описывают реальные процессы

Документация компании не всегда совпадает с тем, как сотрудники действительно работают.

На бумаге процесс может выглядеть так:

А в реальности:

Именно такие скрытые действия часто являются основной причиной разработки новой системы.

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

Требования нужно разделять по смыслу

Не все требования одинаковы.

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

Что является источником истины

Один из главных вопросов корпоративной архитектуры:

где находится окончательно правильное значение данных?

Допустим, у клиента есть:

Эти сведения могут одновременно использовать CRM, ERP и новая система.

Но кто имеет право изменять их?

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

Это принципиальный момент.

Если несколько систем начинают независимо изменять один и тот же объект, очень быстро появляются конфликты.

Модель данных проектируют до интерфейсов

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

Например:

Затем определяются связи.

Когда эти зависимости определены заранее, разработчики не начинают «придумывать структуру базы» непосредственно во время реализации.

Система должна понимать бизнес-объекты, а не только таблицы

Плохой подход:

table_1 / table_2 / table_3 / table_4

Хороший:

За каждым объектом должны стоять понятные правила.

Например, заказ может иметь состояния:

И нельзя просто разрешить пользователю произвольно переводить заказ между любыми статусами.

Состояние должно соответствовать реальному процессу.

Архитектура определяет, как система будет развиваться

На этом этапе решается один из самых важных вопросов:

как разделить систему на части?

Для небольшей системы может быть разумен монолит.

Для крупного решения отдельные сервисы могут понадобиться для конкретных доменов.

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

Архитектура должна соответствовать реальной сложности системы.

Микросервисы нужны не каждой компании

Это особенно важно.

Иногда новый проект сразу хотят построить как десятки независимых сервисов:

На архитектурной схеме выглядит впечатляюще.

Но каждый дополнительный сервис означает:

Если система небольшая, такая архитектура может создать больше проблем, чем решить.

Иногда хорошо структурированный монолит оказывается намного практичнее.

Но монолит тоже нужно проектировать правильно

Монолит не означает «одна огромная программа без структуры».

Внутри него можно разделить доменные области:

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

Интеграции проектируют заранее

Корпоративная система почти никогда не существует в вакууме.

Ей приходится взаимодействовать с:

Поэтому интеграционная схема должна появиться ещё до разработки.

API — не просто способ передать JSON

Хорошая интеграция должна отвечать на гораздо большее количество вопросов.

Поэтому интеграция должна проектироваться как полноценный процесс.

Надёжный обмен требует повторных попыток

Допустим, новая система отправила заказ в ERP.

ERP не ответила.

Это ещё не означает, что заказ не создан.

Если просто повторить запрос, можно получить два заказа.

Поэтому для критичных операций применяются механизмы вроде:

Такие детали редко видит конечный пользователь.

Но именно они определяют надёжность корпоративной системы.

Очереди нужны там, где не стоит ждать ответа

Некоторые операции необязательно выполнять синхронно.

Например:

Сотрудник не должен ждать несколько секунд или минут, пока все внешние системы последовательно обработают запрос.

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

Права доступа проектируют вместе с системой

Ошибка — оставить безопасность на конец разработки.

В корпоративной системе права часто зависят не только от роли.

Получается модель:

И эти ограничения должны проверяться сервером.

Аудит действий особенно важен в корпоративных системах

В какой-то момент появляется вопрос:

Если system не ведёт журнал значимых действий, ответить на эти вопросы бывает невозможно.

Поэтому для важных операций полезно хранить:

Это особенно важно для финансовых, складских и административных процессов.

Интерфейсы проектируют после понимания процессов

Когда бизнес-логика понятна, можно проектировать рабочие места.

Каждая роль получает свой рабочий контекст.

Не нужно показывать оператору всю ERP только потому, что технически это возможно.

Прототипирование позволяет найти ошибки до разработки

Перед программированием полезно пройти ключевые сценарии на прототипе.

Например:

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

После начала разработки изменение архитектурных решений обходится значительно дороже.

Разрабатывать всю систему сразу — не всегда хорошая идея

Большую корпоративную систему лучше разбивать на этапы.

Например:

Так компания получает работающий результат раньше и может проверять решения на реальной эксплуатации.

Но MVP — это не урезанная система

Очень важно понимать разницу.

Плохой MVP:

«Сделаем что-нибудь простое, а потом разберёмся».

Хороший MVP:

«Определим минимальный законченный процесс, который уже создаёт ценность».

Например:

Если этот процесс полностью работает, компания уже получает результат.

А дополнительные функции можно добавлять позже.

Тестирование должно проверять не только кнопки

Для корпоративной системы недостаточно проверить: «Кнопка нажимается».

Нужно проверить сценарий целиком.

И отдельно проверить:

Именно такие сценарии показывают реальную готовность системы.

Логи нужны не только разработчикам

В рабочей системе недостаточно знать, что «что-то сломалось».

Нужно понимать:

Такой журнал позволяет быстро определить, где именно возникла проблема.

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

Мониторинг начинается ещё до первого сбоя

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

Конкретные показатели зависят от системы, но принцип один:

команда должна узнать о проблеме раньше пользователя.

Запуск — это отдельный проект

Даже готовую систему можно неудачно запустить.

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

Поэтому перед запуском нужны:

Миграция данных часто сложнее самой разработки

Если новая система заменяет старое решение, данные нужно перенести.

Особенно сложно, когда в старой базе есть:

Переносить «всё как есть» часто означает перенести старые проблемы в новую систему.

После запуска система только начинает жить

Корпоративная система не заканчивается релизом.

После запуска появляются реальные сценарии, которые невозможно полностью предсказать на этапе проектирования.

Поэтому систему нужно проектировать с возможностью развития.

Хорошая система должна переживать изменения

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

Через два года их становится пять.

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

Если же в модели изначально существует сущность:

система масштабируется намного естественнее.

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

Где чаще всего ошибаются

Как выглядит зрелый подход

Если собрать всё вместе, путь проектирования корпоративной системы выглядит примерно так:

На каждом этапе принимаются решения, которые влияют на стоимость и устойчивость всей системы.

Что на самом деле означает «с нуля»

Разработка корпоративной системы с нуля — это не написание программы с чистого листа.

Это создание нового информационного контура вокруг реальных процессов компании.

При этом существующие системы могут продолжать работать.

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

Здесь нет задачи заменить всё существующее.

Задача — сделать так, чтобы системы начали работать как единый механизм.

Итог

Корпоративную систему с нуля проектируют не с вопроса:

Первый вопрос гораздо важнее:

какой процесс компания хочет получить на выходе и какие системы должны участвовать в его выполнении?

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

Хорошая корпоративная система при этом не обязана быть огромной с первого дня.

Она может начинаться с одного законченного процесса, постепенно расширяясь:

Главное — заложить правильную основу.

Потому что корпоративная автоматизация — это не набор отдельных экранов и не коллекция API.

Это архитектура, в которой данные, процессы, сотрудники и существующие информационные системы начинают работать согласованно.

🔒 Данные и доступ к системам заказчика обрабатываются в соответствии с согласованными требованиями к безопасности и конфиденциальности. Условия доступа, хранения и обработки данных определяются архитектурой проекта и договором.

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).