Direct specialist delivery
You discuss the requirement with the person who investigates the system, makes the change and explains the result. Context stays with the work.
HxGN EAM / Octave Attune EAM
EAM boutique: from requirement to tested change
For EAM owners and delivery partners who need a defined improvement to work in daily maintenance. I clarify the process, implement the change, test the relevant cases and hand over a documented result you can maintain.
Lukas Paul Streiff · EAM product knowledge, operational understanding and hands-on engineering.
01
Buy a complete work package
For a defined EAM requirement, one experienced specialist can cover work that would otherwise be split across several consultant roles. The scope is agreed by deliverables, dependencies and acceptance criteria.
Less coordination to buy
Combining functional and technical work reduces the need for repeated briefings, internal handovers and coordination meetings. Effort can go into the result and its verification.
An explicit commercial scope
You receive defined outputs, assumptions and exclusions. Additional work is assessed against that boundary, so a specific improvement remains a manageable engagement.
Breadth within an agreed scope
Work can span work-order processes, screens, Dataspies, SQL and FlexSQL, JavaScript, reports, APIs and surrounding workflows. Connecting these disciplines helps avoid solving a screen issue while leaving the underlying data or process problem in place.
Breadth of expertise is different from parallel capacity. Multiple simultaneous rollouts, specialist infrastructure work or continuous support need an appropriate team and explicit coverage. I agree those needs before committing to the scope.
Example work package: improve work-order closure
Clarify the closure rules, review fields and permissions, adjust the appropriate EAM configuration or extension, align the report, test normal and exception cases, and hand over the documented change. These steps can form one coherent engagement.
How my delivery model evolved
From an implementation team to a specialist boutique
Before COVID: six people in the company
We focused on standard EAM implementations, especially Start Centres with inboxes, KPIs and FlexSQL. I spent much of my time clarifying processes and speaking with customers; my staff carried out the implementation and also handled smaller project topics directly. EF played a smaller part in our work at the time.
Today: direct specialist delivery
I clarify the customer’s process, implement the agreed improvement and take responsibility for technical review, testing and documentation. AI supports suitable, clearly specified routine work; I direct its use and check the result.
The boutique builds on experience of leading an EAM delivery team. The model changes; process understanding, product knowledge and responsibility for a usable result remain central.
02
The effort shifts from configuration to understanding
With a clear requirement and controlled access, AI can take on routine configuration and coding. The valuable consulting work is deciding what the customer actually needs and preparing that understanding for reliable execution. Complex rules and integration dependencies still require engineering.
-
Understand and specify
Clarify the process with the customer. Define data sources, status meaning, roles, calculation rules, exceptions and examples with expected results. Turn these into a bounded implementation brief.
-
Let AI execute defined work
Use that brief to direct AI through suitable code and configuration tasks, including application steps where appropriate. Limit the scope and permissions, record changes and stop for unresolved business decisions.
-
Validate and take responsibility
Review the implementation against the requirement and test its operational behaviour. The specialist remains responsible for technical review and documentation; the customer accepts the business result before the agreed production release.
03
Product knowledge shapes the implementation
A familiar workaround deserves a fresh check against the actual product version, operating environment and requirement. Experience includes knowing when the standard product already provides a suitable route.
Check the standard first
Review the available configuration, Screen Designer, Dataspy tools and documented integration or extension options before adding custom behaviour.
Make each intervention deliberate
Select the method for the installed version and deployment model. Record dependencies and any exception that needs a specific review or vendor guidance.
Test the operational consequence
Verify fields, permissions, filters, records and downstream results with representative users and cases. Carry the relevant checks into patch and release testing.
An example of the difference
A working screen is the beginning of the evidence
Directly copying or changing internal screen and Dataspy definitions through SQL in database tables, including Oracle tables, can introduce dependencies that are difficult to reconstruct later. SQL used for analysis, reporting or an intended extension point is a different matter.
Consider a field that is no longer visible after a patch or release change. Investigation needs the original configuration, affected user groups, change history and a repeatable test. The symptom alone does not establish the cause; product defects and other configuration changes also need checking.
My delivery standard is to use the appropriate documented product mechanism, record what changed and why, and make the relevant regression checks repeatable. Where a departure is necessary, its reason, risks and recovery path belong in the agreed change.
Release compatibility still needs verification. The practical benefit is a traceable implementation that gives the next maintainer a basis for investigation and controlled correction.
04
Documentation is part of the delivered work
The handover should let your team or another qualified partner understand, test and maintain the result. For the agreed scope, it includes:
- Change inventory
- Affected screens, Dataspies, rules, reports, interfaces and configuration objects, with their versions and dependencies.
- Decision record
- The requirement, selected method, reasons, assumptions and known limitations.
- Implementation record
- Versioned code where applicable, configuration records and reproducible setup instructions.
- Test evidence
- Cases, roles, expected and observed results, exceptions and acceptance status.
- Deployment and recovery
- Prerequisites, sequence, verification steps and a rollback or recovery procedure appropriate to the change.
- Operational ownership
- Responsibilities, open points, support boundaries and checks to repeat before a patch or release change.
05
A focused engagement or a specialist role in your team
The boutique model works when responsibility and delivery boundaries are clear.
For EAM owners
Resolve a defined bottleneck, review inherited customisations or prepare a critical workflow for a release change. Start with one concrete example.
For delivery partners
Bring in functional and technical EAM depth for a defined work package. You retain the client relationship and wider programme ownership; I provide implementation and a documented handover.
Which EAM change needs a reliable result?
Describe one workflow, screen, report or recurring problem and your EAM version. We can identify the useful scope, required access and acceptance criteria for the next step.