Jan Mikoláš
Practical guide
How to design an internal company system
Do not start with a list of screens. Start with the work people will do in the system every day.
First, the short version
What should an internal system solve?
An internal information system helps people finish work correctly and find out what happened. It should not merely move a paper form onto a screen. It should remove needless retyping, unclear handovers, and searches through email.
Roles and permissions decide who may view, change, or approve individual steps. An API then lets you connect accounting, stock, or other services without manual exports.
Get ready
What to learn before the first design
Talk to people who do the work for real. A manager’s view is a useful start, but not a complete process description.
- One concrete process, such as quote approval, a complaint, or buying materials.
- Examples of current forms, spreadsheets, emails, and exceptions. Exceptions are often more important than the ideal path.
- A list of people and teams who create, review, approve, or only read something in the process.
- A list of systems that provide data, and the system that is the source of truth for each important piece of data.
Steps 1 to 3
Design the system from work to screen
The first version should help with one complete process. Do not try to replace every company tool in it.
1. Draw the real workflow
- Pick one case from beginning to end. For example: an employee creates a request, a manager approves it, and accounting closes it.
- For every step, note the input, outcome, responsible person, and what happens when the item goes back.
- Separate record states, such as draft, awaiting approval, approved, and rejected. A state is not a note in a text field.
- Remove steps that exist only because someone used to retype data manually.
2. Set roles before forms
- Do not write rules for specific people’s names. Create roles such as requester, manager, accountant, and administrator.
- For each role, write what it may read and change. RBAC makes the rules clear: a user gets a role and a role gets permissions.
- Check permissions on the server for every sensitive action. A hidden button is not protection. For the decision “may this person change this record?”, use authorization.
- Keep a history of who made a change, when, and from which state to which. In an internal system this is often more important than a beautiful dashboard.
3. Connect surrounding systems with clear ownership
- For each piece of data, choose a source of truth. An employee name may belong in the HR system, not in three separate forms.
- Use an API to transfer only data the other system needs. Do not send a whole database table merely because it is convenient.
- Store changes that do not need to happen immediately for later processing. An accounting outage will then not stop a request being created.
- For every connection, set up logging, an owner, and a simple procedure for a failure.
Step 4
Test the design with a real case
Do not inspect only the happy path. Also try a person with limited rights and a request returned for more information.
-
Walk through one case with a user
Let someone in the target role create and finish one real request. Watch where they hesitate or search for information outside the system.
-
Check access from every role
Sign in as a requester, approver, and administrator. Each should see only the data and actions they actually need.
-
Try a return and an outage
Return a request for completion and simulate an unavailable connected system. The record must not disappear or end up in an unclear state.
If something goes wrong
Common design mistakes
The system has many features, but people bypass it
Return to one process and learn where work gets stuck. Improve the first small step, not another menu and another form.
Everyone can see everything
Split users into roles and check permissions on the server for sensitive actions. Access to data must not depend only on which button is displayed.
The same data is changed in several systems
Choose one source of truth. In other systems, only show or synchronise it. Otherwise the values will eventually drift apart.
Nobody knows why a request is stuck
Keep a history of state changes, connection errors, and the responsible person. Support can then find the problem without hunting through email.
Done
You have the foundation for a system that supports work.
Add further processes one at a time. First understand the work, then set roles, and only then build the screen.