Lean and Kanban for IT Operations: Understand the flow of work and information

Who is your customer?
If you are on a desktop support team, who is your customer?

It's not the team leader.

The customers would be the internal staff that need the new desktop setup, that need a password changed, etc.  You may have people in between who make the requests on their behalf, that is, their manager, but it's probably most useful to consider the end user as the "customer".

If you are on a BAU (business-as-usual) change support team, who is your customer?

It's not the team leader.

The customers really depends on what kind of systems you are supporting.  Some of them may be for internal staff while others may be for external customers.

If you are on a site operations team, who is your customer?

It's not the team leader.

Most of your customers are the external uses of the site / system.  You will probably also have internal customers, for example, application development teams who need to deploy changes.

What are your work flows?
IT Ops teams have multiple work flows related to how many types of customers they have and how many types of work they have.  However, it's not really necessary to map them all.  The most common work flow, that is, the most common work type for the most common customer type, is a good place to start.

So how do you determine an actual work flow?

Look at the work item and follow it from creation to completion to the customer observing what happens to it, who works on it, how long it is worked on, delays that occur, rework that occurs, etc.

How are your work flows managed?
How is the "work on this next" signal sent?

For example, does the team leader triage and assign all the work?  Is it all self-managed through the ticketing system?  What about walk-ups?

What to Do (or really how I do this)
When I do this, it's more about looking around, talking to people, browsing logs, and poking around ticketing systems.  I am trying to understand the flows but I have never actually drawn a map as it never seemed necessary to highlight a particular problem.  The eventual creation of a Kanban board perhaps also reduces my desire to use a drawn map.

This is quite different in software development situations where I've always tended to draw the value stream.  I wonder if this has to do with how overloaded the teams tend to be, the nature of the work, some accidentally developed preference, or something else.

So all I can really suggest at the moment is to focus on shared understanding and experiment with drawing or not to see if it makes things better or worse.