ERP для проектной компании

Public source описывает Corely как внутреннюю ERP-систему для IT-компании. Source-backed scope: 4 ключевые роли — project, employee, owner, admin — и основные модули: planning, time tracking, finance, employees, projects and documentation.

Поэтому публичная версия кейса не должна выглядеть как abstract design-system story. Это ERP for project operations: кто планирует работу, кто списывает время, кто смотрит финансы, кто управляет структурой и доступами.

В ERP такого класса один проект одновременно затрагивает planning, time tracking, finance, employees and documentation. Project role смотрит на сроки и задачи, employee — на свою работу и время, owner — на финансовую картину, admin — на структуру и права.

Главный конфликт: одна сущность проходит через несколько модулей и ролей. Если ownership, status and visibility не зафиксированы в IA, интерфейс быстро распадается на набор локальных экранов.

Source-backed role: product designer from discovery to interfaces. Я проводил интервью с сотрудниками, составлял карту ролей и сценариев, работал в паре с аналитиком, формулировал требования, проектировал flows, interfaces and design system.

В публичной упаковке важно не расширять это до solo ownership всей ERP. Моя зона — продуктовая структура и интерфейсная логика: role/scenario map, IA модулей, states and reusable patterns.

Corely легко переупаковать слишком сильно: ERP, роли, финансы и дизайн-система звучат как большой transformation case. Поэтому proof layer намеренно начинается с source reconciliation.

Source-backed: internal ERP, 4 roles, core modules, interviews, role/scenario map and design-system work. Reconstructed: role/module taxonomy and component patterns. Unknown: client identity, measured metrics, before/after artifact, governance rollout.

Первый слой архитектуры — role × module map: project, employee, owner and admin пересекаются с planning, time tracking, finance, employees, projects and documentation.

В публичном артефакте это показывается как reconstruction: где source подтверждает роли/модули, где выводится taxonomy, а где нужны новые источники. Это демонстрирует IA thinking без раскрытия клиента и без fake before/after.

Source говорит, что ERP покрывает planning and employees и даёт возможность планировать загрузку. В публичной версии это можно показывать как module relationship: проектная роль планирует, сотрудник связан со временем и задачами, owner смотрит aggregate picture.

Нельзя превращать это в claim про ускорение планирования или сокращение ручной сверки: таких метрик нет в source.

Source-backed scope включает time tracking and finance, а также возможность считать profitability, анализировать profit/loss and планировать загрузку. Это сильный product class signal.

Но это не публичная метрика эффективности. В кейсе формулируем это как design problem: time data and finance module должны быть связаны через понятные роли, статусы и ownership.

Public source подтверждает design-system work как часть роли. Конкретные таблицы, состояния, фильтры и большие формы в текущей упаковке показываются как derived taxonomy draft.

Это позволяет показать system thinking, но не заявляет verified governance, token propagation, component ownership или measured rollout effect.

Публично подтверждено: создана внутренняя ERP-система под реальные процессы компании, внедрены 4 ключевые роли, покрыты основные модули: planning, time tracking, finance, employees, projects and documentation.

Публично не подтверждено: скорость согласований, time saved, прозрачность, adoption, profitability uplift or governance maturity. Поэтому финальный слой case copy остается честным supporting proof, а не overclaimed энтерпрайз transformation.