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

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

Появляются интерфейсы, серверы, базы данных, API, mobile приложения. Но до всего этого должен появиться ответ на гораздо более важный вопрос:

В небольшом проекте ошибку на старте иногда можно исправить за несколько дней. В корпоративной системе цена ошибки совершенно другая.

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

Она начинается с обследования.

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

Каждый следующий этап опирается на предыдущий.

Почему нельзя начинать с интерфейсов

Один из самых распространённых сценариев выглядит так.

Заказчик показывает существующую систему или несколько экранов и говорит:

Это полезная отправная точка, но недостаточная постановка задачи.

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

Например, оператор нажимает кнопку «Провести заказ».

За этой кнопкой потенциально находится целая цепочка:

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

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

Сначала нужно понять, как бизнес работает сегодня

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

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

Но при разговоре с сотрудниками выясняется, что между этими этапами существуют:

• › ручная проверка;
• › Excel-файл;
• › звонок в другой отдел;
• › письмо на общий адрес;
• › повторный ввод информации;
• › согласование руководителя;
• › исключения, которые никто не описал в регламенте.

Именно эти места часто становятся главными кандидатами на автоматизацию.

Документация компании не всегда описывает действительность

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

Они необходимы.

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

На практике может существовать разница между:

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

Поэтому хороший анализ сопоставляет несколько источников:

• › документы;
• › интервью;
• › существующие системы;
• › данные;
• › наблюдение за работой сотрудников;
• › реальные исключения;
• › существующие интеграции.

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

Одна из ошибок — проектировать систему вокруг понятия «пользователь».

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

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

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

Требование — это не название функции

Фраза:

сама по себе почти ничего не говорит разработчику.

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

• › кто создаёт заказ;
• › откуда он приходит;
• › какие поля обязательны;
• › можно ли редактировать заказ после создания;
• › кто его согласует;
• › какие статусы существуют;
• › кто имеет право менять статус;
• › какие проверки выполняются;
• › куда передаются данные;
• › что происходит при ошибке;
• › какие документы создаются;
• › какие уведомления отправляются.

Тогда абстрактное требование превращается в процесс.

Например:

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

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

Обычно приходится отдельно фиксировать как минимум:

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

Особое внимание — данным

Корпоративная система в первую очередь работает не с экранами.

Она работает с данными.

Поэтому уже на этапе проектирования необходимо определить основные сущности:

Для каждой сущности нужно понимать:

• › где она создаётся;
• › кто ей владеет;
• › какие идентификаторы используются;
• › какие связи существуют;
• › какие изменения должны сохраняться;
• › какая система является источником истины;
• › что происходит при удалении или изменении записи.

Где находится источник истины

Предположим, клиент существует одновременно в CRM, 1С и новой корпоративной системе.

Если ответ не определить заранее, постепенно появятся конфликты:

И это ещё простой случай.

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

Интеграции определяют архитектуру сильнее, чем кажется

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

Вокруг неё уже могут работать:

Для каждой связи нужно определить:

• › что передаётся;
• › в какую сторону;
• › когда передаётся;
• › кто инициирует обмен;
• › как идентифицируются сущности;
• › что происходит при недоступности системы;
• › как обрабатываются повторные сообщения;
• › кто считается источником истины.

Интеграция — это не просто «подключить API».

Нельзя проектировать интеграции только по счастливому сценарию

На встречах часто обсуждают:

Но настоящий вопрос начинается дальше.

Что произойдёт, если CRM отправила заказ, а новая система была недоступна?

Нужно определить:

• › будет ли повторная попытка;
• › где хранится необработанное сообщение;
• › как долго оно может находиться в очереди;
• › как определить дубликат;
• › кто увидит ошибку;
• › можно ли обработать её вручную;
• › как восстановить процесс после сбоя.

Архитектура появляется из ограничений

После обследования начинает формироваться архитектура.

Она не должна быть набором модных технологий.

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

Архитектура должна учитывать не только сегодняшний день

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

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

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

Поэтому нужен баланс:

Границы проекта важнее списка функций

Очень часто проект пытаются описать длинным перечнем:

Но список функций не показывает границы системы.

Гораздо полезнее определить:

Тогда становится понятно, что система должна делать, а чего делать не должна.

MVP — это не «сделаем половину системы»

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

MVP — не обязательно урезанная версия каждого модуля.

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

И только после этого подключать следующий процесс.

Прототип нужен не только ради дизайна

До полноценной разработки полезно проверить спорные места.

Например, будущий интерфейс оператора:

Но прототип должен отвечать не только на вопрос: «Красиво ли это выглядит?»

Нужно проверить:

• › понимает ли оператор следующий шаг;
• › хватает ли ему данных;
• › не перегружен ли экран;
• › какие действия доступны;
• › что происходит после ошибки;
• › как выглядит исключительная ситуация.

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

В корпоративной системе недостаточно сказать:

Права часто зависят одновременно от роли, подразделения, объекта и операции.

Причём доступ к конкретному объекту может зависеть от организации, филиала, проекта или владельца.

Безопасность тоже начинается до разработки

Безопасность нельзя добавлять в конце как отдельный модуль.

Уже при проектировании нужно понимать:

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

Например:

Что должно получиться до начала основной разработки

К моменту старта разработки команда должна понимать значительно больше, чем просто список функций.

Должна существовать связанная картина:

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

Это не означает, что после старта ничего нельзя менять.

Наоборот — хорошие проекты предполагают изменения.

Техническое решение связывает бизнес и разработку

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

Его состав зависит от проекта, но обычно необходимо описать:

• › назначение системы;
• › границы ответственности;
• › основные пользовательские сценарии;
• › роли;
• › модель данных;
• › интеграции;
• › архитектуру;
• › требования к безопасности;
• › правила доступа;
• › нефункциональные требования;
• › требования к журналированию;
• › стратегия обработки ошибок;
• › требования к инфраструктуре;
• › этапы реализации.

Смысл не в количестве страниц.

Хорошее техническое решение должно позволять ответить на вопрос:

Что происходит после обследования

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

Появляются понятные этапы:

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

Часть архитектуры может уточняться во время реализации, а отдельные интерфейсы — проверяться на пользователях ещё до готовности backend.

Самая дорогая ошибка — начать кодировать слишком рано

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

Команда пишет код, появляются экраны, система начинает работать.

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

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

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

Это состояние, при котором команда понимает:

От обследования к системе, которой можно управлять

Корпоративная разработка начинается не с выбора языка программирования и не с первого макета интерфейса.

Она начинается с понимания того, как компания работает сейчас и что именно должна изменить будущая система.

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

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

И чем больше система, тем важнее именно эта часть работы.

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

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