Разработка ПО
Менеджмент
Для компаний
Для стартапов
Архитектура ПО
В этом проекте автоматизации логистических компаний была нестандартная и рискованая разработка, которую мы не рекомендуем Вам повторять в домашних условиях, но в данном проекте всё закончилось хорошо и с выгодной для заказчика. Административные системы не славятся уникальным и красивым дизайном. Админки чаще делают как попало, лишь бы работало. Но данный клиент - крупная транспортная компания North West - требовал качественный дизайн с упором на UI\UX и стильный интерфейс для всех пользователей данной CRM.
Заказчики называли эту систему просто CRM-кой. Формально же это TMS (Transportation Management System, то есть система управления транспортными процессами). Но если говорить по-человечески, то перед нами был большой рабочий инструмент для транспортного бизнеса, где нужно учитывать компании, водителей, траки, документы, задачи, переписки и статусы. И всё это — без ощущения, что ты с утра снова открываешь цифровой филиал ада =)
Система была предназначена для ведения множества траковых компаний, которые перевозят грузы. Программа учитывает водителей, транспортные средства, документацию каждой организации, отслеживает статусы, помогает планировать задачи сотрудников, содержит внутренний чат и информационную базу. Внутри предусмотрено несколько типов кабинетов для разных ролей: менеджеров, операторов, компаний-клиентов и технической администрации.
По своей сути это многоуровневая B2B-платформа с выраженной ролевой моделью доступа (RBAC, разграничение прав по ролям), состояниями объектов (state machine, допустимые переходы между статусами) и сложным документооборотом. Если вам интересны похожие проекты в логистике и транспорте, обратите внимание также на NorthWest, LEX, Svit BUS, BusTicket и UNO Taxi.
Видео-обзор третьего этапа
На видео зафиксирован третий этап проекта. Более поздние версии не записывались, но даже этот обзор хорошо показывает масштаб интерфейсов и объём уже собранной функциональности.
Особенности разработки
Этот проект был интересен не только предметной областью, но и самим форматом запуска. Заказчик пришёл не столько с готовой аналитикой, сколько с чётким визуальным представлением будущего продукта. Уже на первых переговорах мы согласовали нетипичную для нас модель: основным носителем бизнес-требований становился дизайн.
Обычно мы предпочитаем сначала выделить этап проектирования: описать роли, сущности, сценарии, ограничения, валидации, права доступа и только после этого идти в разработку. Здесь же решение было другим. Из-за необходимости быстро получить результат мы сознательно пошли без полноценного предпроектного этапа и без переоценки бюджета после глубокого анализа.
Это рискованно, но в нашем случае сработало. У нас были собственные средства автоматизации, которые позволяли собирать рабочие контуры системы в сжатые сроки. Особенно помог SFL — структурный фрактальный язык, с помощью которого можно быстро описывать сущности, связи, API и документацию, а не лепить всё вручную по кускам. Параллельно был применён FRACTAL.ingello — наша технология детерминированной генерации кода и ускоренного конструирования приложений. Это не про магию нейросетей и не про случайную генерацию, а про инженерную предсказуемость: когда архитектурный каркас проекта вырастает из его внутренней логики, а не из хаоса.
За считанные недели был подготовлен прототип базы данных, собран программный интерфейс интеграции, административная панель и свёрстаны основные интерфейсы по дизайну. На третьем этапе оставалось сделать самое интересное: связать визуальный слой с backend-логикой, реализовать вспомогательные модули на frontend, завершить чат и программную обработку документов.
Такой формат сотрудничества оказался выгоден заказчику именно в этом кейсе. Но важно понимать: это не универсальная таблетка. Иногда быстрый старт без отдельного проектирования ускоряет путь к результату, а иногда просто переносит боль на более поздний этап. Поэтому разберём честно — где были сильные стороны подхода, а где пришлось заплатить за скорость.
Плюсы выбранного подхода
Дизайн стал общим языком между бизнесом и разработкой
Для административных систем это редкая удача. Обычно бывает наоборот: есть длинное ТЗ, но нет визуальной модели, и каждая сторона представляет продукт по-своему. Здесь же дизайн стал точкой синхронизации. Всё, что касалось интерфейсов, маршрутов пользователя и визуальной логики, согласовывалось быстро и без лишней драмы.
Делегирование задач происходило легко
Так как значительная часть решений считывалась из макетов, мы быстро подготовили внутреннюю документацию и распределили работу по специалистам. Команда не тратила лишние дни на угадывание задумки. Проще говоря, вместо хаотичного футбола задач получился вполне собранный конвейер.
Свобода инженерной трактовки дала скорость
Заказчик доверил нам самостоятельно принимать решения по тем вопросам, которые невозможно буквально прочитать с дизайна. А таких вопросов в живом проекте много: состояния ошибок, пустые данные, сценарии ограничений, скрытые зависимости, логика ролей. Для слабой команды такая свобода — ловушка. Для сильной — серьёзное преимущество.
Удалось быстро выйти на большой MVP
MVP обычно представляют как что-то маленькое, скромное и слегка грустное. Здесь получилось иначе. Благодаря автоматизации и внутренним инструментам мы собрали раннюю версию продукта, которая по объёму возможностей выглядела заметно богаче типичного MVP на рынке. Это тот случай, когда заказчик платит не за обещание будущей системы, а уже видит живой механизм.
FRACTAL дал экономию там, где другие команды раздули бы бюджет
В этом проекте хорошо сработал именно фрактальный подход. Мы нащупали ДНК системы: описали структуру данных, замаппили на неё интерфейсы, автоматизировали сборку повторяющихся слоёв и за счёт этого смогли уместить большой объём функциональности в ограниченный бюджет. В обычной ручной разработке значительная часть денег ушла бы просто на рутину.
Если вам близка тема корпоративной автоматизации, посмотрите также platFORMA, FORMA BPM и FORMA CRM. Это хорошие примеры того, как мы подходим к сложным внутренним системам, процессам и управленческим контурам.
Минусы и ограничения
Отсутствие полноценного ТЗ
Когда логика живёт в дизайне, часть требований всё равно остаётся между строк. Макет не объясняет, кто и при каких условиях может менять статус, какие ошибки должны быть обработаны, как система ведёт себя при пустых или конфликтующих данных. Всё это приходится достраивать уже в процессе разработки.
Большой объём ранней версии потребовал стабилизации
Да, формально это был MVP. Но по факту в нём было слишком много для обычного MVP. Это приятно для бизнеса и слегка жестоко для команды: чем шире ранняя версия, тем больше потом времени уходит на стабилизацию, шлифовку сценариев и выравнивание поведения модулей.
Пришлось принимать компромиссы
При фиксированном и сравнительно небольшом бюджете невозможно бесконечно углубляться в идеальную архитектурную красоту. Где-то решения принимались быстрее, где-то второстепенные улучшения откладывались на следующую итерацию. Это не халтура, а взрослая экономика разработки. И именно поэтому результат удивил заказчика в хорошем смысле.
Главные вызовы проекта
Сложная иерархическая предметная область
По сути это была многоуровневая B2B-система: управляющая сторона, компании-клиенты, сотрудники, водители, транспорт, документы и статусы. Почти B2B2B2B, если смотреть на это после третьей чашки кофе =)
Нет классического этапа проектирования
Мы сознательно отказались от привычной фазы детальной аналитики, чтобы быстрее перейти к работающему продукту. Это ускорило старт, но перенесло часть аналитической нагрузки прямо в разработку.
Фиксированный бюджет и жёсткие сроки
Нужно было собрать большую систему без бесконечного разрастания сметы. Именно поэтому внутренняя автоматизация и повторно используемые решения стали не просто удобными, а стратегически важными.
Не были заранее описаны базовые состояния экранов
Пустые страницы, ошибки, валидации, конфликтующие статусы, ограничения ролей — всё это редко рисуют в красивых макетах, но именно там обычно начинается реальная жизнь продукта. И да, эти вещи пришлось достраивать по ходу.
Решения по функциональности
Суперадмин
На этом экране показан кабинет верхнего уровня управления платформой. Суперадмин получает централизованный контроль над системой, может управлять менеджерами компании и фактически держит в руках общий управленческий контур. Это не просто настройки, а точка контроля над ролевой моделью и структурой всей платформы.
В рамках этой роли были реализованы функции управления менеджерами компании, базовые административные действия и глобальный контроль над внутренней организацией системы.
Менеджер
Это уже основной рабочий кабинет менеджера. Здесь собраны быстрый доступ к ключевым разделам, управление клиентами и компаниями, мониторинг событий, календарное планирование и внутренняя коммуникация. Именно такие экраны превращают систему из набора вкладок в реальный инструмент ежедневной работы.
Менеджер видит панель быстрого доступа, контролирует организации, следит за событиями, планирует задачи и общается внутри системы без необходимости перепрыгивать между внешними сервисами.
Компания-клиент
На этом скриншоте показан кабинет компании-клиента. Это уже не уровень управляющей стороны, а пространство для ежедневной операционной работы перевозчика: траки, водители, документы, задачи, календарь и чаты. То есть не абстрактная цифровизация ради модного слова digital, а конкретный рабочий инструмент.
Внутри этого кабинета были реализованы дашборд, календарное планирование, внутренние переписки, управление транспортом и водителями, а также загрузка документов с контролем их состояний.
Техническая админка
Отдельным слоем мы собрали технический контур системы. Это особенно важно в сложных корпоративных продуктах: бизнес должен видеть свои процессы, а команда сопровождения — здоровье самой платформы. На таких экранах живут инструменты, которые потом спасают от лишних ночных приключений.
Здесь были предусмотрены журнал ошибок, состояние сервера, общие сводки данных, управление учётными данными и справочниками.
Служебные и административные разделы
Этот экран показывает, как техническая администрация работает не только с ошибками и статусами, но и со справочниками, системными настройками и внутренними структурами данных. Именно такие разделы делают систему сопровождения зрелой, а не декоративной.
Планирование и рабочие интерфейсы
Общий экран управления задачами
Этот экран показывает, что система не ограничивалась регистрацией сущностей и хранением документов. В ней был полноценный операционный слой: планирование, контроль статусов, работа с задачами и быстрый переход к действиям. Иными словами, это уже не просто база данных с красивыми кнопками, а рабочая среда для команды.
Годовой календарь с цветовой маркировкой
Здесь показан формат годового календаря с маркировкой задач по категориям через цвета. Такой интерфейс помогает мгновенно увидеть плотность процессов, сезонные пики и перегруженные участки. Для менеджмента это удобно: система не просто хранит задачи, а визуально показывает, где назревает перегрузка.
Интерактивный календарь
А здесь уже интерактивный календарь по месяцам и годам с уведомлениями о задачах и возможностью быстро принимать решения по ним. Это тот слой продукта, где данные превращаются в повседневное управление: напоминания, действия, статусы и дедлайны сходятся в одной точке.
Профиль и персональные настройки
Профиль пользователя
На этом скриншоте — профиль с загрузкой фото, настройками уведомлений в виде тумблеров и возможностью смены пароля. Такие модули часто недооценивают, хотя именно они сильно влияют на ощущение целостности продукта. Пользователь должен чувствовать, что система умеет работать не только с компаниями и документами, но и с ним самим.
Загрузка персональных файлов
Здесь видно, как в профиль можно загружать файлы и фотографии с персональной информацией. Это важно, потому что в корпоративных системах документ почти никогда не существует сам по себе. Он должен быть привязан к человеку, сущности, роли и конкретному рабочему контексту.
Документы и статусы
Реестр документов
На этом экране представлен список документов с датами загрузки и настройками. Здесь особенно хорошо видно, что документооборот в системе не декоративный, а рабочий. Каждый документ проходит через свой жизненный цикл: загрузка, проверка, статус, доступные действия и связь с объектами системы.
Транспорт и компании
Реестр траков
Этот экран показывает список траков, VIN-коды и возможность настроить каждый объект отдельно. Здесь уже видно предметное ядро платформы: транспорт как полноценная сущность со своими атрибутами, идентификаторами и рабочими действиями.
Компании и транспорт в одном контуре
На данном скриншоте показан список компаний и траков с возможностью настройки. Система связывает разные уровни предметной области в одну управляемую картину: организация, её транспорт, сотрудники и документация больше не живут в разных таблицах и мессенджерах.
Загрузка и обработка документов
Здесь показан ключевой рабочий сценарий: загрузка документов, их обработка и отслеживание статусов. Для транспортного бизнеса это один из самых чувствительных контуров системы. Документ здесь — не просто файл, а причина действия, подтверждение процесса и иногда главный источник операционной боли, если с ним что-то не так.
Единая управленческая панель
На этом экране собран обзор компаний, траков, водителей и полного набора документации. Это хороший пример композитного интерфейса, где несколько взаимосвязанных сущностей соединены в единую управленческую панель. Меньше переключений, меньше потери контекста, меньше шансов что-то упустить.
База знаний и поддержка пользователей
Раздел вопросов и ответов
Здесь показан раздел вопрос-ответов по системе с возможностью задать свой вопрос, получить ответ, а после модерации — автоматически пополнить базу знаний. Это полезный слой продукта: он снижает нагрузку на поддержку и постепенно превращает разрозненные обращения пользователей в накопленную полезную память системы.
Календарь задач
Задачи на день и детализация статусов
На этом скриншоте календарь уже показывает список задач на конкретный день и позволяет по клику провалиться в детальную информацию. Такой формат удобен тем, что соединяет обзорность и оперативность: менеджер видит нагрузку по дате и тут же может перейти к конкретным действиям.
Внутренние коммуникации
Чат для общения и обмена документами
А здесь уже внутренний чат. В корпоративных продуктах это очень важный модуль, потому что люди всё равно будут общаться по задачам, файлам и статусам. Вопрос лишь в том, будут ли они делать это внутри рабочего контура, где сообщения связаны с объектами системы, или снова утонут во внешних мессенджерах, где через два дня никто ничего не найдёт.
Технологии
Почему этот стек дал заказчику реальное преимущество
Сам по себе список технологий никого не впечатляет. Заказчика интересует не набор модных слов, а ответ на простой вопрос: почему именно с этим стеком проект получился быстрее, дешевле и управляемее. В данном кейсе технологии были важны не как украшение тендера, а как инструмент экономии времени, бюджета и нервов.
SFL позволил ускорить прототипирование базы данных, API и документации. PHP дал предсказуемую серверную основу для сложной бизнес-системы. JavaScript, HTML и CSS обеспечили живой и понятный интерфейсный слой. Linux, BASH, Docker, Docker Compose, FastCGI Process Manager, MySQL и Nginx дали стабильное серверное окружение и управляемую эксплуатацию.
Но главное преимущество дал не просто стек, а то, как он был собран вокруг FRACTAL.ingello. Именно фрактальный подход позволил резко сократить долю ручной рутины, быстрее собрать каркас системы и уместить в бюджет объём функциональности, который у обычной команды часто заканчивается словами это уже будет во второй фазе. Здесь многое вошло сразу. И именно поэтому заказчик получил не просто MVP на бумаге, а большую, живую, насыщенную систему, которую можно было показывать, тестировать и развивать дальше.
Если вам интересны другие проекты, где мы строили не просто интерфейсы, а полноценные управленческие контуры, посмотрите platFORMA, FORMA BPM, FORMA CRM, а также транспортные кейсы NorthWest, LEX, Svit BUS, BusTicket и UNO Taxi.
Почему заказчики приходят к нам с такими проектами
Мы умеем работать там, где у других начинается хаос
Сложные системы редко начинаются с красивого порядка. Обычно они начинаются с усталых сотрудников, таблиц, ручных действий, пересылки документов, несвязанных сервисов и ощущения, что всё как-то держится, но непонятно на чём. Именно в таких условиях и нужен не просто подрядчик, а технический партнёр, который умеет раскладывать хаос на сущности, роли, статусы, сценарии и архитектуру.
Мы не продаём иллюзию лёгкой разработки. Мы помогаем пройти путь от туманной идеи или запутанной операционки к системе, которую можно масштабировать, поддерживать и использовать без постоянного ручного героизма. Для этого мы совмещаем проектное мышление, архитектурную дисциплину, автоматизацию и трезвый взгляд на бюджет.
Для заказчика это даёт не абстрактную разработку, а конкретную выгоду
Во-первых, вы получаете не набор программистов, а команду, которая умеет думать о бизнес-процессе целиком. Во-вторых, мы умеем быстро входить в сложную предметную область и вычленять главное. В-третьих, наши внутренние технологии ускоряют путь от идеи к рабочему продукту и снижают количество дорогой ручной рутины. И наконец, мы не заинтересованы бесконечно раздувать проект — нам выгоднее построить систему так, чтобы она была понятной, устойчивой и экономически оправданной.
Если у вас уже есть набор таблиц, регламентов, чатов и нестыкующихся процессов — это можно превратить в рабочую систему. Если у вас только идея и понимание, что нужен сильный технический партнёр — это тоже наш формат. Мы умеем начинать с архитектуры, с анализа, с проектирования, с MVP и с постепенного поэтапного запуска. Главное — делать это не вслепую, а правильно.
Ненавязчиво, но честно
Если вам близок такой подход, загляните на systems.ingello.com. Там есть описание принципов работы, этапов сотрудничества, отзывов, формата взаимодействия и возможность оставить заявку на консультацию. Без громких обещаний и цирка. Просто можно спокойно обсудить ваш проект, понять его реальную сложность и собрать решение, которое будет работать не только в презентации, но и в жизни.
