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: кто планирует работу, кто списывает время, кто смотрит финансы, кто управляет структурой и доступами.

• 01Source-backed roles: project, employee, owner, admin
• 02Source-backed modules: planning, time tracking, finance, employees, projects, documentation
• 03NDA-safe: имя клиента, реальные процессы и метрики не раскрываются

В ERP такого класса один проект одновременно затрагивает planning, time tracking, finance, employees and documentation. Project role смотрит на сроки и задачи, employee — на свою работу и время, owner — на финансовую картину, admin — на структуру и права. Главный конфликт: одна сущность проходит через несколько модулей и ролей. Если ownership, status and visibility не зафиксированы в IA, интерфейс быстро распадается на набор локальных экранов.

• 01Один project object проходит через несколько модулей
• 02Каждая роль видит разные права, статусы и решения
• 03Detailed access rules остаются source gap, не public fact

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.

• 01Source-backed: interviews, role/scenario mapping, requirements with analyst
• 02Source-backed: flows, interfaces, design system
• 03Boundary: не solo ERP ownership and no measured rollout claim

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.

• 01Source-backed: ERP, 4 roles, planning, time, finance, people, docs
• 02Reconstructed: role/module taxonomy and component pattern draft
• 03Unknown: metrics, before/after proof, 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.

• 014 roles and core modules are source-backed
• 02Role/module taxonomy is reconstructed
• 03Access rules, ownership details and before/after remain source gaps

• ▸ artifact · Artifact · source reconciliation + taxonomy

  Corely source reconciliation and taxonomy draft

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

• 01Source-backed: planning and employees modules
• 02Reconstructed: relationship between project work, people and time
• 03Unknown: time saved, manual reconciliation reduction

Source-backed scope включает time tracking and finance, а также возможность считать profitability, анализировать profit/loss and планировать загрузку. Это сильный product class signal. Но это не публичная метрика эффективности. В кейсе формулируем это как design problem: time data and finance module должны быть связаны через понятные роли, статусы и ownership.

• 01Source-backed: time tracking and finance modules
• 02Source-backed: profitability/profit-loss analysis as product capability
• 03Unknown: measured financial, speed or reconciliation outcome

Public source подтверждает design-system work как часть роли. Конкретные таблицы, состояния, фильтры и большие формы в текущей упаковке показываются как derived taxonomy draft. Это позволяет показать system thinking, но не заявляет verified governance, token propagation, component ownership или measured rollout effect.

• 01Source-backed: design-system work
• 02Reconstructed: tables, states, filters, forms taxonomy
• 03Unknown: governance, ownership, token propagation, rollout metrics

Публично подтверждено: создана внутренняя ERP-система под реальные процессы компании, внедрены 4 ключевые роли, покрыты основные модули: planning, time tracking, finance, employees, projects and documentation. Публично не подтверждено: скорость согласований, time saved, прозрачность, adoption, profitability uplift or governance maturity. Поэтому финальный слой case copy остается честным supporting proof, а не overclaimed энтерпрайз transformation.

• 01Source-backed: internal ERP for real company processes
• 02Source-backed: 4 roles and main modules
• 03Unknown: speed, approvals, adoption, profitability or governance outcomes