Проектирование систем и интеграций

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

← Все услуги

Связаться с нами ↗

Для кого

Компании, где учётная программа, система ЭДО, CRM и три таблицы хранят разную правду об одном и том же счёте
Продавцы Uzum и ритейл: остатки в учётной программе, заказы в кабинете маркетплейса, оплаты в Payme/Click — и никто их не сверяет
Финтех, edtech и сервисные компании, которым нужно встроить идентификацию личности и электронную подпись в онбординг и подписание
Основатели, которые собираются заказать платформу и хотят спроектировать модель данных и интеграции до сметы на разработку
Команды, которые приняли систему от прошлого подрядчика и хотят понимать, как она устроена и кто что в ней меняет

Проблема

Бухгалтерия у нас в одной программе, электронные счета-фактуры в другой, продажи в CRM, заказы в кабинете продавца Uzum, а склад на самом деле работает в Telegram-группе.

Ваш Telegram

✓ 11:20 · пришло

Сайт и учётная программа показывают одинаковый остаток. Ничего не продано дважды.

Как это выглядит сегодня

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

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

Что изменится в бизнесе

Одна модель данных на весь бизнес: клиент, заказ, счёт, платёж и товар определены один раз — тот же счёт вводится один раз, а не четыре
Слой интеграций вместо связей «каждый с каждым»: учётная программа, система ЭДО, идентификация личности, электронная подпись, Payme/Click и Uzum общаются с одним API, и замена одной системы не означает переписывания остального
Мультитенантность там, где она нужна: филиалы, франчайзи или компании-клиенты работают в одной системе, а их данные разделены на уровне базы через row-level security
Журнал изменений на каждую запись — кто, что, когда, до и после — и вопрос «кто поменял цену?» решается фильтром, а не совещанием
Правила работы с данными и карта хранения: какие поля — персональные данные, какие остаются на серверах в Узбекистане, какие могут уйти провайдеру модели
Смета на разработку, с которой можно спросить с любого подрядчика: модули, интеграции, дни, риски — годится и для нашей разработки, и для вашей команды

Три шага, именно в таком порядке.

Шаг 1
Разбор систем
30 минут онлайн и один день внутри ваших систем. Разбираем, как настроена ваша учётная программа, берём выгрузку-образец из каждого источника, выписываем каждое место, где один факт вводится дважды, и разговариваем с теми тремя людьми, которые сводят цифры в конце месяца. Результат: инвентаризация на одной странице и вопросы, на которые должен ответить спринт.
Шаг 2
Дизайн-спринт: 10 рабочих дней
Рисуем модель данных, слой интеграций и журнал изменений, затем прогоняем их на ваших реальных выгрузках: загружается ли вчерашний файл продаж из учётной программы без ручного шага, находит ли колбэк Payme свой счёт. Ревью с вашим бухгалтером и программистом, который ведёт учётную программу, на пятый и десятый день. Каждое решение записано с обоснованием, чтобы через полгода его не переспаривали.
Шаг 3
Разработка с нами или вашей командой
Проект — ваш. Мы можем собрать первый модуль сами и передать его с runbook, либо ваши разработчики строят по нему, а мы раз в неделю смотрим их pull request. В любом случае проект не зависит от нас.

Что вы принимаете по акту

Карта процессов и разбивка на модули: что строим и в каком порядке
Сами связи, работающие между вашими системами
Интеграции с системами, которыми вы уже пользуетесь, — насколько эти системы это позволяют
Документация и инструкции для пользователей простым языком
Обучение для каждой роли в вашей команде

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

Дешевле самой проблемы — иначе скажем прямо.

По договорённости

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

Вопросы, которые задают в первом разговоре.

Можно ли уйти с этим проектом к другому подрядчику?

Да, и это как раз проверка. Результат спринта — документ, не привязанный к нам: архитектура, модель данных, список интеграций, риски и смета в днях. Отдайте его любой команде и получите сопоставимые предложения. Если разработку продолжаем мы, стоимость спринта вычитается из первого счёта; если нет — документ всё равно остаётся у вас.

Где будут храниться наши данные? По закону персональные данные граждан должны оставаться в Узбекистане.

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

У нас уже есть учётная программа. Вы сможете с ней работать?

Да. Если вы уже пользуетесь учётной программой или другим специализированным ПО, мы можем интегрироваться с ним — при условии, что сама система допускает интеграцию. Тогда данные вводятся один раз и попадают туда, где нужны. Как именно подключаемся, решаем на этапе проектирования, до первой строки кода.

Сколько это занимает и что происходит после десятого дня?

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

Кому принадлежат проект и код? Могут ли наши разработчики им пользоваться?

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

Свяжитесь с нами.

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