About
A research lab before anything else.
Not a team, not a portfolio. A place to study a specific gap, and a person doing the studying.
Why YX Lab Exists
YX Lab didn’t start with a product, a client, or a funding round. It started with a smaller, more specific observation: a system can be implemented correctly and still leave people working around it, and almost nobody goes back afterward to study why.
That gap, between a system working as designed and people actually using it well, is what YX Lab studies. It’s a research question before it’s anything else.
Who’s Doing This
I’m Kary. My background is in people operations, behavioral coaching, and product and UX work, watching how people adopt or resist a new process depending on how it was introduced to them, not just what the process technically does.
That background is why YX Lab treats process research and behavioral research as one activity rather than two. A process map that ignores how people actually behave around it is incomplete. A behavioral observation that ignores the process it happens inside of is just an anecdote. Put together, they explain more than either does alone.
Why SAP, Specifically
Enterprise systems are where the gap between design and lived experience shows up most clearly and most expensively. A transformation can be technically successful, on time, on budget, fully implemented, and still fail to change how work actually happens, because the people side of the change was never studied with the same rigor as the technical side.
SAP process transformation became the professional focus for exactly that reason: not the only place this gap shows up, but a place worth building real depth in, through study, training toward certification, and applied case work, rather than treating as one interest among many. What that focus covers right now lives on the SAP page. It’s a developing focus, not a claim to implementation history that doesn’t exist yet.
The Standard the Work Is Held To
It would be easy to write about this work the way a lot of consulting content is written: confident, polished, light on specifics. YX Lab doesn’t do that, for a practical reason as much as a philosophical one. Claims without evidence don’t hold up under a second conversation with the same operator or the same SAP team. They just create a credibility problem later.
So the standard is plain: publish what was actually observed, be specific about what remains uncertain, and never claim an outcome, a certification, or an implementation that hasn’t happened. That discipline is slower to build a reputation with. It’s also the only version of a reputation that survives someone checking the work.
How the Pieces Fit Together
Reading how a process actually runs, talking with the people inside it, and turning those observations into field notes and frameworks that can be checked against more evidence later, is what this looks like day to day. Applying that thinking to a real engagement happens only when it’s a genuinely good match, and being honest in public about what worked and what didn’t is part of the deal, not an afterthought.
The measure of progress here isn’t how large YX Lab becomes. It’s whether the next piece of research is more rigorous than the last one.