To design a tailor-made****** management, please ask which screens the customer wants. A screen is only the visible part of rules, roles, data and exceptions that must be understood before development.
The correct path gradually reduces uncertainty: first on the problem, then on the flow, finally on technology.
1. Analyze the current process
The first phase describes what really happens, not what should happen according to an ideal procedure.
For each activity it is necessary to identify:
- who initiates it;
- what information you need;
- where they are recovered;
- who controls or approves;
- which documents are produced;
- how the state of work changes;
- which exceptions occur;
- as you understand that the activity is finished.
Interviewing only the manager can not suffice. Those who run the process every day know informal steps, shortcuts and problems that often do not appear in the official procedure.
2. Define goal and success criteria
“Digitalizing the process” is too generic. A useful goal describes an observable change, for example:
- avoid the double insertion of a request;
- always know who must do the next action;
- generate a document from the data already collected;
- reduce the time needed to prepare a report;
- make visible the state of a contract;
- prevent unauthorized changes.
You do not need to promise a percentage before you have data. It is necessary to establish what will be measured before and after.
3. Translate the process into requirements
Requirements define system behavior. They must include normal cases and exceptions.
A specific clear requirement:
- role of action;
- required data;
- expected result;
- conditions that prevent action;
- notifications or updates generated;
- track that must remain available.
Functional requirements and quality requirements are also distinguished at this stage: security, performance, backup, accessibility, data export and operational continuity.
4. Establish the first useful version
The MVP, or first useful version, should not be a huge management with half of the incomplete functions. It should solve the problem core well for a defined user group.
A practical priority divides requests into four groups:
- indispensable to perform the process;
- necessary to reduce the risk;
- useful but deferable;
- hypothesis to be validated after real use.
This choice influences directlycost and feasibility of management.
5. Prototyping flows and interface
Before development it is useful to make visible navigation, main screens and critical steps. A prototype allows people to recognize conceptual errors when correcting them costs little more.
During the review not only ask “you like it? ”. Ask instead:
- Where would you look for this information?
- What action would you do next?
- What should happen in case of error?
- What data should not be visible to this role?
- What is missing to complete a real case?
The design of a management must make evident the state of work and reduce unnecessary decisions, not only appear modern.
6. Design data and migration
Each function depends on the data. We need to define entities, relationships, states, identifiers and validation rules. If there are previous archives, the migration should be planned before release.
The plan should clarify:
- which sources will be imported;
- who is responsible for quality;
- how to treat duplicates and missing fields;
- which historical data retain;
- how to verify the result;
- when interrupting the use of the old system.
Importing everything without selection can make the new management more difficult to use since the first day.
7. Develop and control for increments
The development proceeds better in verifiable parts. Each increase should include behavior, controls, error management and risk-provided testing.
Artificial intelligence can accelerate prototyping, repetitive code production and some controls. It does not replace the revision of requirements, safety design or testing with realistic data.
8. Testing with who will use the system
Technical tests verify that the software does what was designed. Tests with users verify that the process can really be done.
Prepare test cases means include:
- normal path;
- incomplete or incorrect data;
- change of manager;
- cancellations and reopenings;
- users without permission;
- unavailability of integration;
- realistic volumes;
- export and recovery of information.
Comments must become traced corrections, unsolicited scattered in chat.
9. Prepare release and training
Correct software can fail if the operating pass is not organized. Before release, they must be defined:
- accounts and permits;
- definitive import;
- pass date;
- responsibility during the initial period;
- training by role;
- channel to report problems;
- return plan in case of critical blockade.
Training should use examples close to everyday work, not an abstract overview of all buttons.
10. Measure and evolve management
After the release compares the criteria set out at the beginning: times, errors, steps, requests for assistance and data quality. The new functions should respond to evidence, not accumulate because they seem interesting.
Maintenance also means security updates, backups, integration control and external service verification. Liability and costs must be defined in the contract.
Minimum documentation to be kept
A sustainable project should leave at least:
- process map;
- approved requirements;
- roles and permits;
- data model;
- integrations and credentials under customer control;
- test cases;
- release, backup and restore instructions;
- maintenance and evolution conditions.
This documentation reduces dependence on people who remember how the system works.
If you want to understand if your process really requires dedicated development, please consult the E-ROE service fortailor-made software and managementor compare beforestandard and custom business software.
Frequently asked questions
Where do you start to create a customised management?
From the current process map: roles, steps, data, tools, exceptions and goal. The screens come later, when it is clear what the system has to make easier.
What is the MVP of a management?
It is the first useful version that covers the main problem for defined users. It is not an incomplete demo: it must allow a real test, but it avoids developing functions that are not yet validated.
When do data migrate?
Migration is designed during analysis and tested before release. Sources, cleaning, field correspondence and controls must be defined in advance.
Who should participate in the tests?
People who really do the process, along with those who are responsible for it. They must try normal cases, exceptions, permits and realistic data before release.