Our approach · TreeSolid Systems GmbH
Processes drawn true, then built to run. Our approach follows one idea: a process must be drawn true before it is built. We model work in BPMN, agree the scope with the people who do the work, and build in stages that users can test — including the artefacts you receive and the decisions you make along the way.
Written for clients who want to judge fit and transparency before starting. Am Siebgraben 14, 16727 Oberkrämer · Monday to Friday, 9:00 AM – 6:00 PM.
Assessment and process discovery
We run interviews, follow a case from intake to completion, and collect the forms and exports involved. Systems, interfaces, and data owners are listed. The output is a status-quo description that users recognise as their daily reality. Discovery usually reveals two or three findings that change the original plan — that is a good outcome, because it happens early, while change is still cheap.
BPMN modelling workshop
In the workshop the current process becomes a BPMN diagram with tasks, roles, gateways, and system connections. Participants correct the diagram until it matches their understanding. Decisions are marked where a person must act rather than software. The model becomes the reference for scope, testing, and training — and gives management a picture of the whole flow instead of a list of complaints.
Scope and options
With the model in hand we compare options: configuration, low-code, custom build, RPA, or process change. Each option is described with effort, operating cost, and maintenance demands. The scope for the first release is chosen deliberately, with later phases named but not built. A written scope protects both sides from gradual drift — and makes clear what a first step can and cannot do.
Design of screens and interfaces
Users see the main paths early and comment on wording, fields, and order. Interface specifications define what each system sends, receives, validates, and logs. Error cases are designed here, not discovered in production. German Mittelstand teams often work with such specifications because they support later audits and handovers — everyone can trace a field back to the model step that created it.
What you receive: annotated screens for the main paths, a field and validation list, and an interface specification your IT partners can build against.
Implementation in iterations
A working approval flow matters more than a large code package nobody has seen. Feedback from users is collected after each iteration and folded into the next. The process model is updated when reality changes — that habit keeps the diagram and the software aligned throughout the project, so the sheet on the wall stays true.
Tool choice follows the design, not the other way around. Microsoft Power Platform fits many internal apps and flows in Microsoft 365 environments. SAP Signavio and similar tools fit enterprise process governance. Custom code fits logic that needs close control or high volume. We explain the cost and skill implications of each route, so clients can challenge the choice because the reasoning is on the table.
Testing uses real cases, including incomplete documents, duplicate records, and missing approvals. Test cases are derived from the BPMN model, so each path has a test. Users perform acceptance testing on the tasks they will do daily. Defects are recorded with the process step that produced them, and a test report closes the phase and names what remains for launch support.
Training covers daily tasks, error cases, and the escalation path when something fails. Documentation includes the final process model, interface descriptions, and user guidance, so new staff can learn the system from those documents. Training is scheduled before go-live, not after complaints begin — the effort is modest compared with the cost of a system used incorrectly.
Launch and cutover
Open cases are finished in the old system or migrated with rules. The new flow starts on an agreed date, with support available in the first weeks. We monitor volumes and error rates against the baseline from discovery, and a short hypercare period lets the team settle into the new routine. Cutover planning is part of delivery, not an afterthought.
Adoption decides whether automation pays. We ask users what still slows them down and record the answers. Some findings lead to small changes in the next release; others reveal process rules that need management decisions. Feedback is treated as data, not as resistance — companies that include frontline staff in design usually see faster adoption.
After launch, the system needs updates when other software changes, when volumes grow, or when rules change. Interface monitoring shows failures before users report them. Small improvements are batched into regular releases, and the process model is reviewed when the process changes. Maintenance is a planned activity with a budget, not a series of emergencies.
How to start
Bring the people who do the work and the names of the systems involved. Send a short description to [email protected] or use the contact page. We respond with the questions needed for a first assessment and a proposal for the discovery phase. No large commitment is needed to begin.
