Web Apps & Business Systems

How the work runs.

1. 01

   One process, one record chain

   The point of a business system is fewer handoffs, so the first design question is which record travels through the work and where it has to be visible to the next person. Screens and modules follow from that answer, not the other way round.

2. 02

   Roles and permissions before screens

   Roles state who creates a record, who works on it, who approves it and who may only read it, including the cases where one person must not approve their own work. Permissions are agreed from the operating rules rather than added later as a fix.

3. 03

   Exceptions are part of the scope

   Every process has cases that do not fit: a missing document, a duplicate submission, an order that has to be split. Listing those before implementation is what keeps the system usable on a bad day rather than only on a good one.

4. 04

   Written scope before implementation

   The scope fixes the process, roles, records, permissions, rules, exceptions and acceptance conditions, and states what is deliberately left out. Work begins after you confirm it, which is also what makes the fee understandable.

5. 05

   Where this has been delivered

   The eManage operations platform runs workforce supply, customers, workplaces, orders, assignments, attendance, settlement and reporting on one record chain, with modular workflows, permissions, documents and audit trails. E-User is its worker-facing counterpart, and the operational workbench keeps project state, live tasks, evidence links and follow-up queues in one daily surface. All three are described in the project stories below.

6. 06

   Start with one chain, not the whole company

   A first system that covers one process end to end is more useful than a broad system that covers every process partially, because people will actually use it and the remaining gaps become visible from real records. Modules outside the agreed scope stay on the list for a later stage rather than being half-built now.