Projects & topics
What needs doing
in your project.
I handle system integration, migrations, automation, and troubleshooting in IT projects. These examples show how I connect software development with reliable operations.
Six example project situations
Where’s the problem?
Choose a situation. Each example shows the starting point, what I check and take on, and the result we aim for.
How the process changes
Two identifiers. Changes must be entered twice.
Responsibility is clear. Data and errors follow a defined path.
Example / Integration
Duplicate entry.
Different data.
An order system and accounting hold the same customer under different identifiers. Changes are entered in two places. Eventually, the data no longer matches.
Explore the technical details:
Explore APIs and system integration at DataSource
What I check
Which system is responsible for each field? I check identifiers, interfaces and how incomplete data is handled.
What I take on
I develop the mapping and data flow between the systems. Retries and errors also get a clear, traceable process.
The intended result
Changes are recorded in the agreed place and transferred. Errors remain visible and can be handled.
How the process changes
The switch is coming. What needs to keep running has not been established yet.
Test first, then switch. A rollback remains part of the plan.
Example / Migration
A switch is coming.
Some work remains.
A migration has stalled or a server move is coming up. Data and daily processes depend on it. I can join for the unfinished part and take the change through to a verified result.
Explore the technical details:
Explore business IT and operations at DAXS
What I check
I identify services, data states and dependencies. A trial run shows what works in the new environment and where work remains.
What I take on
I address the outstanding issues and prepare data reconciliation, the time window, checks and rollback. We coordinate the switch with those responsible.
The intended result
The new environment has been checked. The switch and remaining tasks are documented; responsibility for ongoing operations is clear.
How the process changes
The error disappears on the next attempt. The guesses remain.
The error can be explained and reproduced as a test.
Example / Troubleshooting
The application waits.
Or fails.
An application is slow or a process occasionally fails. On the next attempt, it works. The error message alone does not explain the cause.
What I check
I bring together inputs, timings and logs. I check queries, locks, network paths and processing through to the response.
What I take on
I narrow down the cause and implement the agreed fix. It is checked against the specific error case and related processes.
The intended result
The cause can be demonstrated. The fix is testable and the error case remains clearly documented.
How the process changes
The systems exist. Knowledge, tasks and responsibilities need to be organized.
A documented starting point and agreed responsibilities make the handoff clear.
Example / Taking over
The environment runs.
The knowledge is missing.
The previous contact person has left. Documentation has gaps and tasks remain unfinished. I learn the environment and establish a clear starting point.
What I check
I clarify access, users and permissions, inventory servers and services, and check backup and recovery. Dependencies and outstanding tasks become visible.
What I take on
I organize the documentation, prioritize tasks with you and stabilize critical areas. We agree on the areas I take on and who remains responsible for what.
The intended result
The existing setup, priorities and responsibilities are recorded. Individual areas can be handed over in an orderly way or receive continued support.
How the process changes
Each workstation is configured individually. Exceptions are difficult to trace.
A tested process connects setup, checks and handoff.
Example / Rollout
New workstations.
A consistent baseline.
Several devices need to be configured or replaced. Currently, configurations vary between workstations. Experience or capacity is needed at short notice for the rollout.
Explore the technical details:
Explore workplace IT and ongoing support at rnm
What I check
I check applications, devices, user permissions and setup and handoff processes. A pilot shows which exceptions need to be considered.
What I take on
I define the common baseline, standardize setup and take on the agreed part of the rollout, including checks and documentation.
The intended result
The workstations are configured using a clear process. Exceptions and support responsibilities are documented.
How the process changes
The same process is carried out manually over and over.
The agreed part follows defined rules. Exceptions remain visible.
Example / Automation
The same tasks
every day.
Files are transferred manually, data is added later or reports are repeatedly produced in the same way. The process takes time and is difficult to trace.
What I check
I walk through the actual process: inputs, rules, exceptions and errors. We establish which part can sensibly be automated.
What I take on
I implement that part, test it with typical and invalid inputs, and make the process and necessary interventions visible.
The intended result
The recurring task follows defined rules. Errors are visible; operation and maintenance are documented.
Now your
project.
Found a situation that fits? Briefly describe your task. We will discuss the next step personally.