How to document daily operations like "create new accou

[Burki]

Hi all,

I am working for an application service provider who is currently trying to document all of its processes (not only ITIL processes). There have been problems because standard procedures like creating a new user account are not being documented and consequently not being followed.

The problem is: I don't know at which level to stop.
During a brainstorming session we identified processes like
- install program A
- install program B
- install new printer
- create new user account
- delete user account
- Incident Management
- Problem Management
- Release Management
- and so on

We try to create a (high level) process map, but I'm not sure how to structure it and where to put which process.

Did anyone document not only ITIL processes but also processes like "creating a new user account"? There are a lot of those daily operations and we want to document them. Did anyone try to do the same and how did you proceed?

Your suggestions would be highly appreciated!!

Regards,
Burki

[Guerino1]

Hello Burki,

You may want to start by simply ensuring a "sequential/ordered task list" for each process. The first thing that everyone thinks of when documenting processes is taking the time to diagram and document everything. However, over 90% of what is important in any process are the tasks that must be performed, with some level of order to them. Starting with nothing more than such task lists will allow you to create a "check list" of everything that needs to be accomplished, so that those managing the processes can simply check off each task as it's done. Only if the teams managing and using the processes need more than that, should you help to improve those check lists into far more detailed process flows and documentation.

An ordered list of tasks for each process will at least allow you a very quick baseline of your enterprise.

My Best,

Frank Guerno, CEO
TraverseIT
On-Demand ITIL

[joeblough]

The very first thing you need to do is to define each group and their responsibilities.

As a suggestion, this is how I will define these groups:

Service Desk:
- install program A
- install program B
- install new printer

Access Control:
- create new user account
- delete user account

Once you have given each group their responsibilities, it becomes easy to assign individuals the job of documenting their job functions.

I understand that this is not an easy or quick task. It takes time and patience to go through this.

[Guerino1]

Hello Joe,

Another approach (which basically does the same thing but reverses what you described) is to take a "Service identification first" approach, where you identify your services and who's responsible for them...

Service List

Service A : Help Desk
Service B : Engineering
Service C : Help Desk
Service D : Purchasing

What I personally like about this approach is that it can then also be broken down further, into Service-specific Tasks and you can even see natural interleaving between services...

Service A : Help Desk then equates to:

- Task A.1 : Help Desk (starts/kicks-off the Service)
- Task A.2 : Engineering (Equivalent to Service B Task B.1)
- Task A.3 : Purchasing
- Task A.4 : Engineering (Equivalent to Service B Task B.2)
- Task A.5 : Engineering (Equivalent to Service B Task B.3)
- Task A.6 : Help Desk (ends the Service)

When done, you almost have a mini-Project Plan, with a sequential flow of Tasks and accountable Organizations (even Roles and/or People if you want) that helps you get a map of what needs to be done and who's accountable for the work. This now also gives you a high-level check-list that you can stay on top of for getting that work done. It also starts to allow for easy mapping across Processes and/or Services (even Projects).

Anyhow, I hope this helps.

My Best,

Frank Guerino, CEO
TraverseIT
On-Demand ITIL