For a retail group, the central system question is rarely whether an isolated feature exists. It is whether the platform can accommodate changes in organisation, brands, data, interfaces and workflows over time.
A small network first needs store opening, checkout, products, stock and basic management. A group must also manage multiple brands, legal entities, regions, store formats and stages of development. Product attributes, prices, promotions, loyalty, inventory, store processes and reporting gradually diverge.
A feature list describes current capabilities. Selection must also establish which capabilities can be reused, which differences are configurable, which require integration or development, and how changes will be tested, released and maintained. A shared platform needs explicit boundaries between reuse and brand independence.
1. Why retail groups need a common foundation
Separate POS, CRM, mini-program, ordering and reporting systems may offer short-term flexibility but create duplicated purchasing and interfaces, inconsistent metrics and multiple support relationships. Adding brands can mean rebuilding basic capabilities.
Conversely, identical rules for every brand can erase necessary differences. Luxury beauty, professional cosmetics, fragrance, sportswear, collectible toys and beauty care do not share all product attributes, promotions, benefits or service processes.
A practical approach combines mature retail products for established store, loyalty, inventory, ordering and mini-program operations with a common technical foundation for organisational permissions, workflows, data models, integrations and page configuration. Brands share a product foundation but use different depths of capability; group governance coexists with defined operating boundaries.
This does not mean all rules are identical or that low-code can deliver every requirement immediately. Confirm each difference through configuration, integration or custom development within the project.
2. Separate shared standards, brand independence and project decisions
| Layer | Examples | Purpose |
|---|---|---|
| Group-wide | Organisation and account framework, permission principles, data standards, metrics, interface specifications and audit requirements | Reduce duplication and establish governance |
| Brand-specific | Product attributes, prices, promotions, loyalty clubs, store workflows, reports and specific channels | Preserve operating logic and data boundaries |
| Project-defined | Master-data ownership, inter-entity settlement, stock responsibility, history migration, exceptions and system roles | Clarify scope, ownership and acceptance |
Use this classification in both design and acceptance. Permissions must govern not just menu access but brands, stores, customers, orders, stock and fields, together with creation, approval, export and editing rights.
A group role may view authorised aggregates without automatically receiving all customer details or marketing permissions. Brand teams should operate within their own data boundaries. Audit access to logs should not grant promotion-configuration rights.
PEKON Omnichannel CRM & Loyalty Platform supports multi-organisation architecture and multi-brand deployment, with separate loyalty rules and data scopes. Do not assume identities, points, coupons, stored value or marketing permissions are shared. Agree group-level aggregates, brand-level isolation and any cross-brand contact requiring customer authorisation and business approval.
Group stock analysis may compare value, turnover, shortages, expiry and sell-through, while ordering, replenishment, transfers, counts and responsibility remain allocated by brand, legal entity, warehouse and store. Shared warehouses or inter-entity settlement need explicit stock ownership, reconciliation and exception design.
3. What PEKON Jingang Low-Code PaaS can support
PEKON began building its PEKON Jingang Low-Code PaaS in 2017 as part of its move towards SaaS. Its described capabilities include low-code development, visual configuration, workflow and rules engines, data models, API orchestration, pipelines, monitoring and error handling.
The PEKON Smart Retail System, CRM, B2B Ordering Platform and WeChat Mini-programs deliver business functions. The PaaS provides a common technical foundation for differences in data, workflows, rules, interfaces and pages.
It is not a promise that any requirement will be fast or inexpensive, nor permission for business users to change production systems at will. Classify changes as standard functionality, configuration, integration, custom development or unsupported, then specify delivery ownership, tests, release timing and maintenance.
| Change | Potential components | Evidence to test |
|---|---|---|
| Add a brand or entity | Organisations, roles, permissions and data models | Template reuse with isolated data and operations |
| Change approvals or store workflows | Processes, rules, pages and tasks | Scoped effects, testing and release controls |
| Add a channel or system | APIs, mappings, sequences and exception handling | Clear ownership and detectable, recoverable failures |
| Add metrics or analysis | Models, definitions and pipelines | Consistent sources, calculations, periods and access |
| Enter a region or store format | Combined organisations, pages, rules and interfaces | Reusable standard scope and owners for differences |
In a US premium-beauty group project, the PEKON Smart Retail System connected mini-programs, CRM and ERP on a multi-brand retail platform, covering complex promotions, mobile checkout, online-order imports and data distribution. This demonstrates relevant project experience, not automatic reuse of every capability for every group. ERP, WMS, OMS, finance, governance and security requirements still require discovery and POC validation.
4. Six steps to building a group retail foundation
- Define business and system boundaries. Allocate responsibilities across retail, CRM, ordering, mini-programs, ERP, WMS, OMS, finance, e-commerce and BI. Specify who creates and maintains data and which results return to other systems.
- Create a shared-versus-isolated inventory. Classify organisations, products, prices, promotions, customers, stock, staff, reports and interfaces down to fields, roles and processes.
- Assign master-data and metric ownership. Record source systems, definitions, update responsibilities and quality standards. Define aggregate versus detailed access, calculation periods and organisational scope.
- Use the five capability categories. For every requirement, record the implementation route, owner, deliverable, acceptance method and maintenance arrangement.
- Validate a representative scope. Run products, transactions, stock, loyalty, permissions, reporting and interfaces for a brand, region or typical store group. Check accuracy, failures and effects on other brands.
- Establish ongoing change control. Record request origin, scope, category, version, tests, release date and owner. Check existing templates before adding configuration, integrations or development.
5. Evidence group IT should request in a POC
A smooth demonstration is insufficient. Require reviewable evidence of implementation, boundaries and maintenance.
| Evidence | Review question |
|---|---|
| System boundary diagram | What do POS, CRM, B2B, mini-programs, ERP, WMS, OMS, finance and BI own? |
| Master-data responsibility matrix | Who creates, changes and returns products, members, stores, staff, stock, prices and orders? |
| Permission matrix | What can group, brand, region, store, IT, finance and audit roles view, export, approve or change? |
| Interface inventory | Are direction, mappings, frequency, retries, compensation and reconciliation ownership explicit? |
| Change and release process | How are configuration, workflows, pages, interfaces and code tested, approved, released and rolled back? |
| Logs and audit scope | Are price changes, returns, exports, permission changes, stock adjustments and identity merges traceable? |
| Isolation tests | Is Brand A prevented from accessing Brand B’s member, order, inventory and reporting details? |
| Peak-load tests | What capacity and fallback strategies apply to promotions, loyalty days, openings, imports and retries? |
| Acceptance checklist | Are standard, configured, integrated, custom and unsupported items treated separately? |
These records distinguish demonstration readiness from the governance needed for continued operation.
6. Design demonstrations around the same change scenarios
Ask each supplier to demonstrate the same scenarios and explain scope and maintenance:
- Add a brand: identify reusable organisation, role, store, payment, interface and reporting configuration, and what must change.
- Test whether Brand A can view, export or alter Brand B’s products, members and orders, and how authorised group aggregates work.
- Change one brand’s approval process or promotion and test effects on other brands, including approval and release controls.
- Connect a new ERP, e-commerce platform or service, showing mappings, call order, retries and reconciliation ownership.
- Add a group metric with explainable sources, calculation, organisational scope and access.
- Classify current requirements and identify who maintains each after launch.
- Retire a brand or change loyalty rules while preserving appropriate history, entitlements and reporting definitions.
- Interrupt an interface and demonstrate store continuity, recovery and failure tracking.
Record three forms of evidence for each: observed results, the implementation route and confirmed project scope. Together they show operational behaviour, future change costs and delivery responsibilities.
7. PaaS boundaries and governance
PaaS does not replace decisions about brand roles, shared data, isolated workflows or ownership of master data and metrics. Clear business boundaries precede configuration.
It also need not replace every enterprise system. Mature finance, warehouse, fulfilment and e-commerce systems can retain their responsibilities through agreed integrations.
Low-code changes to organisations, permissions, models, workflows and interfaces still require requirements review, configuration or development, testing, approval, release and operational checks. Extensibility does not make every requirement a supported commitment. Product combinations, data scope, interface count, deployment, timing and custom work depend on discovery and POC results.
8. The value is controlled, maintainable change
As PEKON supports brands from first store to group operations, system priorities move from opening on time towards continued evolution. Mature products provide established business capabilities; the common PaaS accommodates organisational, permission, data, workflow, page and API differences.
Assess whether each change can be classified, tested, released, traced and maintained. Explainable and validated organisational boundaries, data scope, interface ownership and change processes are what allow a common foundation to become a long-term operating platform.
Frequently asked questions
How does a shared foundation differ from building from scratch?
It starts with mature retail products and a common PaaS, handling differences through standard capabilities, configuration, integration and development. Building from scratch requires more foundational work and different delivery, risk and maintenance responsibilities.
Must every brand use identical product, promotion and loyalty rules?
No. Organisation frameworks, data standards, interfaces and audit can be shared while product attributes, pricing, promotions, loyalty clubs, store workflows and reports remain brand-specific. Agree the boundary inventory before implementation.
Can business users directly change production through low-code?
That should not be assumed. Implementation teams normally configure or develop approved requirements through testing and release controls. Business users define rules and accept results without bypassing governance.
Must ERP, WMS, OMS and finance be replaced?
No. Existing systems can retain suitable responsibilities. Clarify boundaries, source data, interface direction, exceptions and maintenance rather than consolidating everything by default.
Should a new brand simply copy another brand’s configuration?
No. Reuse suitable organisation, role, store, payment, interface and reporting templates, but configure product, price, promotion, loyalty-club, beauty-adviser and channel differences. Validate data, permissions, transactions, stock and integrations before launch.
Stores can have different promotions configured centrally and executed at the front end. Current price changes require a store manager’s authorisation code. A configured minimum discount prevents submission below the permitted price—for example, below 80% of the original price when that is the floor. This uses one manager-authorisation level; it does not support escalating approvals based on discount depth.
How can a group test adaptability?
Use actual brand additions, workflow changes, new metrics, integrations, isolation checks and interface failures. Require outcomes, implementation routes, capability categories, applicability and maintenance arrangements.
Should every business difference enter the PaaS?
No. Be selective about responsibilities already handled by specialist systems, unvalidated one-off requests and changes whose cost exceeds long-term value. Confirm scope through discovery and the five capability categories.