Загружаю страницу…
supporting · 2022 · поддерживающий
В проектной компании процессы жили в разных местах: планирование, время, финансы, сотрудники, проекты и документы. Я помог разложить роли и модули так, чтобы система стала похожа на рабочий продукт, а не на набор разрозненных разделов.
role
Продуктовый дизайнер
фокус работы
Роли, модули и понятная структура
year
2022
tags
ERP · Проектная модель · Несколько ролей
§ 01 · Контекст
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: кто планирует работу, кто списывает время, кто смотрит финансы, кто управляет структурой и доступами.
§ 02 · Проблема
В ERP такого класса один проект одновременно затрагивает planning, time tracking, finance, employees and documentation. Project role смотрит на сроки и задачи, employee — на свою работу и время, owner — на финансовую картину, admin — на структуру и права.
Главный конфликт: одна сущность проходит через несколько модулей и ролей. Если ownership, status and visibility не зафиксированы в IA, интерфейс быстро распадается на набор локальных экранов.
§ 03 · Роль
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.
§ 04 · Как читать proof
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.
§ 05 · Архитектура
Первый слой архитектуры — role × module map: project, employee, owner and admin пересекаются с planning, time tracking, finance, employees, projects and documentation.
В публичном артефакте это показывается как reconstruction: где source подтверждает роли/модули, где выводится taxonomy, а где нужны новые источники. Это демонстрирует IA thinking без раскрытия клиента и без fake before/after.
§ 06 · Сценарий · ресурсы
Source говорит, что ERP покрывает planning and employees и даёт возможность планировать загрузку. В публичной версии это можно показывать как module relationship: проектная роль планирует, сотрудник связан со временем и задачами, owner смотрит aggregate picture.
Нельзя превращать это в claim про ускорение планирования или сокращение ручной сверки: таких метрик нет в source.
§ 07 · Сценарий · время → деньги
Source-backed scope включает time tracking and finance, а также возможность считать profitability, анализировать profit/loss and планировать загрузку. Это сильный product class signal.
Но это не публичная метрика эффективности. В кейсе формулируем это как design problem: time data and finance module должны быть связаны через понятные роли, статусы и ownership.
§ 08 · Системный слой
Public source подтверждает design-system work как часть роли. Конкретные таблицы, состояния, фильтры и большие формы в текущей упаковке показываются как derived taxonomy draft.
Это позволяет показать system thinking, но не заявляет verified governance, token propagation, component ownership или measured rollout effect.
§ 09 · Результат
Публично подтверждено: создана внутренняя ERP-система под реальные процессы компании, внедрены 4 ключевые роли, покрыты основные модули: planning, time tracking, finance, employees, projects and documentation.
Публично не подтверждено: скорость согласований, time saved, прозрачность, adoption, profitability uplift or governance maturity. Поэтому финальный слой case copy остается честным supporting proof, а не overclaimed энтерпрайз transformation.