Ryoshi

Ryoshi Lean ITSM for Enterprise IT | Transforming your Reactive Support Ticketing into Efficient Service Delivery - without adding tools or headcount.

Subscribe to the Lean ITSM Newsletter here:
https://www.ryoshi.de/en/newsletter/

A year to decide. A year to implement.That was the rhythm of an IT manager I worked with for several years.He was curiou...
03/09/2026

A year to decide. A year to implement.

That was the rhythm of an IT manager I worked with for several years.
He was curious, honest, communicative, and he knew about technology.

Nevertheless, he was not successful.

By the time anything was changed in his department, he already lost the support of his team.

Every idea went through an endless loop. Talking about what could be done. Talking about what should be done. Getting to a decision took close to a year. Getting it done took another year.

Yes, that's an overly dramatic picture, but in some cases that's exactly how it went.

Somewhere in that stretch, one colleague after another gave up on the idea. Not because the ideas were wrong, but because nothing moved fast enough to keep them on track.

Many IT employees seem to love exploring and discussing options because of uncertainty.

I've see this behavior across IT departments in companies of various sizes.

Organizational development for service delivery and support is set on hold.

In order to get things done anyway, some might hire an external consultant. Which gets expensive fast, and the knowledge is lost when the contract ends.

Others might look for a community instead, just to discuss the same problems on repeat. Still, nobody has to actually decide anything.

If that loop sounds familiar, you don't need another meeting. You need people who'll hold you to a decision and make you take action.

These people are the SDM Impact Club. A closed community for any kind of Service Delivery or Service Desk Managers who hold each other to deciding and acting, not discussing.

SDM Club will open in Q4 2026, once the waitlist reaches 100 signups.

Join the waitlist here: sdm-club.com

I’m looking forward to see you there.

Felix

P.S.: Founding members get their first month free.
P.P.S.: You still have questions? Send me a message.

IT employees don't lose their work day on technology only.Tom, an IT professional, wants to make his daily work more eff...
02/09/2026

IT employees don't lose their work day on technology only.

Tom, an IT professional, wants to make his daily work more efficient and is looking for technical solutions to do so. His team colleague Anna, on the other hand, blames the outdated tools. And their manager Frank, he's asking to speed up, to fulfill all the business requirements.

All want to improve their work. All have an idea what to do. All are losing their time somewhere.

Here are six things that prevent IT employees from improving their efficiency:

1. Unfounded priorities: „Just do this first, we need it asap.“
No reason given. No benefits explained.

2. Context-based habits: „Open the tool; click here; check this; do that;“
The context triggers the habit - unquestioned.

3. Unknown impacts: „That's not a big issue at the moment.“
Assuming low impact, while the urgency is rising.

4. Missing statistical figures: „The average looks fine. No trend is visible.“
Average values cover up the underlying patterns.

5. Misunderstandings (communication): „I thought that’s what you meant.“
Assuming that we all share a common understanding.

6. Technical debt: „The tool is too old.“
The only one that's actually technical.

Look at the list again. Five out of six are not about technology.

These five won't shows up in a ticket count. They shows up in overtime, unpredictability, and in good people quietly considering to leave the company.

Now check your IT strategy. Is it mostly people-first or tech-first?

Fix the process before you fix the tool. That's the people-first answer.

I write about exactly this in the Lean ITSM Newsletter: link on top ⤴

Felix

The beach was beautiful. The wastage wasn't.That's why my last vacation left me uneasy.It was an all-inclusive hotel, ri...
01/09/2026

The beach was beautiful. The wastage wasn't.

That's why my last vacation left me uneasy.

It was an all-inclusive hotel, right next to the beach. All meals were served as an open buffet: fresh omelets, fruits, bakery and soft drinks.

I watched people grabbing and stacking all of it onto their plates. When they left, the table looked like a second mini-buffet, still full of food.

I hate to be wasteful. So I hate to see wastage.

On the way home, I started looking for the reasons and studies as evidence.
There are multiple: Habits, excuses, missing price tags and moral licensing.

One reason matters most to me: the environment is designed for waste.
The abundance is staged on purpose, because guests read a full buffet as high quality.

One study proves, that reducing the plate size by only a little cuts food waste by around 20%.

Now, let's apply it to IT services.

Company IT often looks the same way to the employees: all-inclusive, no price tag, invisible consumption - it’s there anyway.

This way, users are unintentionally invited to waste IT resources.

There's one item on most IT service catalogs doing the same job as that buffet plate: no limit, no price, wide open.

I'll show you exactly which one it is, and what replaces it, in my next newsletter.

Subscribe to it here: link on top ⤴

Felix

You didn't skip anything in that training. That's exactly why it failed.A week after the process training, the same ques...
11/08/2026

You didn't skip anything in that training. That's exactly why it failed.

A week after the process training, the same questions came back, about the parts you already explained.

You covered everything. Every step, every exception, every "what if someone asks." The whole department sat through it. There was even a short quiz at the end.

Then days go by and the first questions roll in. On topics you spent 20 minutes explaining, in detail.

Sounds familiar?

Here's what actually happened. You built that training out of the fear that someone would say afterward "nobody told me that." So you packed in everything, just to be safe.

The content was fine. There was just too much of it.

People don't remember everything you tell them.
They remember what's relevant to their day.

So the relevant question isn't "did we cover it all." It's "what does this specific group actually need." A field technician needs the exceptions. A service desk agent needs the escalation paths. Neither needs all the information.

Build your next training around the role, and three things shift:

a) The content becomes a thread people can follow.
b) Nobody gets overwhelmed by irrelevant cases.
c) Follow-up questions drop, because the right people got the right information.

This matters most in large IT organizations, juggling a dozen roles and just as many process variants. That's exactly where covering everything backfires.

Read more on building service operations that hold up under complexity in my Lean ITSM Newsletter: Link on top ⤴

How my 2nd level support team went back on track.We had to cut the average incident lifetime in half.Not the way you are...
04/08/2026

How my 2nd level support team went back on track.

We had to cut the average incident lifetime in half.

Not the way you are thinking.

There was no new tool. There was no new headcount.

Ask an IT leader what it takes to get there, and you'll answers like:

– Hire more people or outsource.
– Run a big automation program.
– Execute a consolidation project.

All three need budget, a business case, and a year of your work life.

So the work never starts.

The team keeps handling the escalations and everyone gets used to it.

Here is an alternative - four steps - no purchase order:

1. Collect all of the possible causes.
Not only the popular one - all of them. Ask the people who resolve those tickets every day. They already know. Likely nobody ever asked them properly.

2. Turn each cause into a sentence.
„Tickets that get reassigned too often.“
„Information is missing in the tickets.“
„Too many requests for information.“
Write them down. Aim for more than ten.

3. Test each one against your ticket data.
Most of them won’t be confirmed. That’s the useful part.
Some will be confirmed, and these are worth changing.

4. Change how those specific tickets get handled.
Then tell everyone what changed and why.
The telling matters as much as the change itself.

That was the whole intervention we did.
Average incident lifetime dropped by half.
Escalations stopped.

It's what I call the Improvement Funnel.

Why does it work?

Delay is not spread evenly across your queue. It sits in a few specific places - we call it 'factors'. Most teams never look, because they assume the answer is either beyond control or too expensive.

You can copy this. Schedule a one hour workshop for steps 1 for tomorrow.

Before you start, find out what that delay is already costing you. The RCA ROI Calculator turns it into a euro figure your CFO will respond to: https://www.ryoshi.de/rca-roi/

In a factory, 1000 defects a month starts an investigation.In IT, it starts a monthly report.Picture a production line.T...
30/07/2026

In a factory, 1000 defects a month starts an investigation.
In IT, it starts a monthly report.

Picture a production line.

The plant manager asks how the week went. The line manager says:
"Strong week. We handled 3 outages and produced 186 faulty parts."
He would not get any praise. He would get a root cause analysis.

In IT we do the opposite:

We count incidents handled. We put the number in a report.
And the teams learns exactly what get’s measured.

More incidents means more visible work.
More visible work means more value.

Nobody says that out loud, yet everybody feels it.

But every incident is still a failure. It adds no value.

That’s necessary work - not productive work - and never a priority you want to grow.

Three numbers that actually show productivity instead:

1. Standard services delivered. How much of the month was planned, repeatable, designed work? That is real output.

2. Automation rate. How much of that standard work ran without a person touching it? At one construction client we moved from 11% to 33%. Same tool. Same team.

3. Incident trend. Which team has fewer incidents this month than last? This number proves something actually got fixed.

You don’t get better service by handling failures faster.
You get better service by producing less failures.

Do this today: open your last service report. Count how many numbers describe failures handled, and how many describe actual delivery work that was designed. In most of the reports I’ve see, the former is more common.

Then find out what these failures are costing you, with the RCA ROI Calculator: https://www.ryoshi.de/rca-roi/

Which number does your management ask for? 💬

--

P.S.: Rebuilding that measurement set is week one of our IT Service Turnaround Program. If you want to do it together, send me a message.

Many group employees complain about micromanagement, even though they also play their part in it.Support agents process ...
28/07/2026

Many group employees complain about micromanagement, even though they also play their part in it.

Support agents process a large number of tickets every day. Small mistakes in ticket handling pull them into micromanagement.

Six exemplary things that are annoying in corporate ticket handling:

1. Playing Ticket Ping-Pong
„Just reassign the ticket ‚somewhere‘ else.“

2. Stretching the time limits
„That issue can wait. The SLA is not yet at risk.“

3. Ask just one question at a time
„Are you (requester) still facing this issue?“

4. Let tickets go stale silently
„...“

5. Vague statements without evidence
„That’s not down to us (team).“

6. Not adding a resolution comment
„Resolved.“

None of these are tool debts. They are rooted in working culture.

The danger is that the more these things are happening, the more they are done by others as well.

So, if you want to avoid this happening and prevent micromanagement, discuss these specific individual cases within the team, and give concrete handling instructions for each.

If you’re in this situation, don’t expect things to change quickly. This behavioral change requires discipline and some time.

It results in more efficient work and happier staff.

--

I've prepared 10 metrics every IT Service Ops should be tracking. Get it along with the Lean ITSM Newsletter, link on top ⤴

No RFP can prevent the most expensive mistake in a tool selection.It will set you back a six-figure sum and the risk to ...
23/07/2026

No RFP can prevent the most expensive mistake in a tool selection.

It will set you back a six-figure sum and the risk to do it all over again, if you ignore it.

Not because platform is wrong.

But because a single person picked it. Behind closed doors. Nobody who'd actually work on the tickets was really involved.

This way, the implementation will meet resistance from day one.

And two years after go-live, the company might start over with a different platform.

I've also seen the opposite: Companies that involve in the people who'd use the tool every day, before anything got decided. The agents closing tickets. The employees opening them. Not just the leadership team covering the bill.

The difference shows up early and lasts long. Commitment is already there at go-live. And acceptance lingers.

Here's what a detailed requirements catalog can't buy: a room full of people who are committed.

If you're choosing your next service management platform, spend less time perfecting the spec. Spend more time getting the people involved. The people who will live with the decision to be made.

Right from the start, not after the contract has been signed.

--

More on involving people the right way, in the Lean ITSM Newsletter: https://www.ryoshi.de/newsletter

Your gut is telling you the services aren't performing that well.Your gut is right. And no AI is going to fix this.I say...
21/07/2026

Your gut is telling you the services aren't performing that well.

Your gut is right. And no AI is going to fix this.

I say this as someone who spends his weeks inside enterprise IT operations, not as someone selling against AI.

The technology is fine. Your reflex is the problem:

You know something feels off in the team. Tickets stay untouched. Problems keep coming back. The best people are exhausted. You can't quite name the cause, so it stays a feeling. And feelings are hard to bring into a budget meeting.

A tool is easy to bring into a budget meeting.

Redemption lies in the hope of the sales promises.

An AI helpdesk agent. An automation layer. A copilot for the service desk.
Something concrete, something fundable, something that doesn't require saying the uncomfortable truth: the way we operate has a limit, and we've hit it.

But AI doesn't remove organizational limits.

If no one is in charge of the ticket queue, AI won’t be either.

If the process has no designed end to end flow, AI automates the gaps along with the steps.

If the team compensates for broken processes with more communication, AI is just putting on top.

Processing speed is not your limiting factor anymore. So more processing speed won’t make a big difference.

I have seen resolution times drop 66% and automation rates triple at enterprise IT teams. In none of those cases did we start with new technology. We started with the process and the operating model of the team: who owns what, how work flows, where it stalls, and why. The tools came in afterwards.

This order is not a preference. It's the reason the numbers moved.

Your gut feeling is telling you the constraint is organizational?

Trust it before funding another tool.

--

Want to give your gut feeling a name? Start with a Service Management Audit Call, here: https://ryoshi.de/audit

We got paid for every ticket we closed.A thousand-euro bill every month.So nobody bothered to change that.I managed the ...
16/07/2026

We got paid for every ticket we closed.

A thousand-euro bill every month.

So nobody bothered to change that.

I managed the service delivery for an external MSP.

The contract was simple: A base fee and a price per ticket.

One task showed up ten times a week. Every week.

Adjusting a value in a database, manually, because the original workflow never covered it.

500+ tickets a year. 125 hours of work. A five-figure invoice. For a process gap that could be closed forever.

Look at the conflict of interest:

Fixing the gap would lower the bill by 500 tickets. So the provider loses revenue for doing better work.

No contract says that out loud.

That's the problem with a pay per ticket model. It doesn't buy you service. It buys you tickets.

And whatever you pay for, you get more of.

(Editor’s note: Of course that’s different for sole service desk providers, who just take calls and are not involved in the actual service design and delivery.)

Flat fees have other traps. Price scales too. But at least these models make prevention profitable. Under pay per ticket, prevention is a cost - always.

Here's what most service reviews miss:

Asking the people who actually resolve the tickets, which ones come back every day. They can name them instantly.

Then do the math. Frequency x handling time x hourly rate. Compare it with the one-time cost of fixing the root cause.

That number tells you whether your compensation model works for you or against you.

Do you reward your provider for handling tickets - or for prevention? 💬

I built an RCA ROI Calculator that does this math for you. Try it here: https://www.ryoshi.de/en/rca-roi/

Adresse

Aidlingen
71134

Telefon

+4970349424200

Webseite

, ,

Benachrichtigungen

Lassen Sie sich von uns eine E-Mail senden und seien Sie der erste der Neuigkeiten und Aktionen von Ryoshi erfährt. Ihre E-Mail-Adresse wird nicht für andere Zwecke verwendet und Sie können sich jederzeit abmelden.

Service Kontaktieren

Nachricht an Ryoshi senden:

Verknüpfungen

Teilen

Kategorie