Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.
Note: ® ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.
Search
Languages
Select Interface Language:
Advertising
Please contact us via the feedback page to discuss advertising rates.
Joined: Mar 16, 2006 Posts: 12 Location: Rennes, Brittany, Fr
Posted: Thu Dec 28, 2006 6:51 pm Post subject: Process inventory
Hello,
I am in charge of an ITIL migration. I am first working on a process inventory. Before making the mapping to ITIL processes, I am trying to rank the existing documents by kind :
- Processes
- procedures
- Work Instructions
- Templates
- Technical Instructions (when they have to do with the process)
I have done a similar thing. A slightly different approach using Prince2 methods. Treat ITIL Implementation as a project and use the product breakdown as a way of identifying all the products,; i.e Procedures, templates etc. Its a good way to show in one frame the 'big picture'. An implemetation strategy or framework is key, The Itil books help here also. Put the effort into the planning and you will succeed. Good luck and sucess.
I think what you are doing is definitely one of the things you need to do.
However, I would spend some time assessing the overall situation first, which will give you the pain areas and the areas where you have the most to gain. Then I would brush an overall program plan in big strokes and establish priorities.
Part of that plan is a communication and education program. Because this is much about culture change, it takes time and lots of efforts in communication. You will always be better off communicating a lot and taking the time to win hearts and minds...
Based on an overall business case just enough to sustain a program coordination, I would get senior management support. Then I would manage each program elements as a formal project, justifying priority and investments, and measuring results every step of the way. _________________ BR,
Fabien Papleux
Accenture
Technology Consulting | Service Excellence
Red Badge Certified
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Sun Dec 31, 2006 1:51 am Post subject:
Hello Toutencarton,
When you say you are working on a process inventory, do you mean the collection and understanding of your current processes or on an inventory of ITIL processes that you will or won't be looking to roll out?
Or, do you mean that you are working on the inventory of artifacts you will need to support the process?
Regards,
Frank _________________ [Edited by Admin to remove link]
Joined: Aug 11, 2006 Posts: 262 Location: Netherlands
Posted: Sun Dec 31, 2006 4:02 am Post subject:
Hi,
Besides looking at your documentation (which is important), do not forget the human aspect (acceptance etc.). Have a look at John P Kotter's 8 steps for succesfull change (search on the web). Very simple stuff, yet often forgotten.
During ITIL implementation I found out there is a need to implement some other practices.
First was to introduce document management procedures.
It is good to build Document Library for the organisation you work for.
It is not only categorisation but also introducing naming conventions,
approval workflows and policy of document reviewing and archiving (if they are not valid any more).
People negligence is a great enemy in introducing processes.
Your idea is good.
I also like the idea of document management from PRINCE2.
I also made an article once about my experience with documentation: en.sdjournal.org/?module=products&moduleAction=articleInfo&value=127
An area raised in other threads relates to measurment of process success ( the KPIs ). The document management is I agree very important to have document control, audit and tracking. Automated is a good idea.
Joined: Mar 16, 2006 Posts: 12 Location: Rennes, Brittany, Fr
Posted: Mon Jan 08, 2007 11:34 pm Post subject:
Thank you for all your answers.
Actually, the process inventory I am working on is the inventory of what exists, ITIL compliant or not.
Only in a later step, I will choose priorities in processes to improve and move the existing to ITIL.
Concerning the document library, I think that it will come naturally when I will begin to rank the documents in categories.
My great question is : as it is impossible to make everyone learn the procedures (in a environment made of people most interested in technology than in company organisation), how to make something easy to use from high level processes to very technical work instruction (assuming that time is an essential factor in case of incident) ?
In fact I am "enforcing" pople to learn basics of processes during trainings and checks it with some (not hard) tests.
To have easy solution with process/procedure description I am using some web-system: click-able Visio drawings with flows linked to webpages with step/activity descriptions.
Enforcement can be made easier if the business benefit is demonstrated. Why are you doing this guys? Here's the benefit scores. Eureka, so if we follow these processes we get this business gain, profit, bonus, customer retention etc... Unless effort is shown to deliver reward then human nature tends to shirk away from doing stuff. Try and develop a dashboard that can be used to modify behaviour ( the right behaviours ). Food for thought?
Joined: Jan 01, 2006 Posts: 500 Location: New Jersey
Posted: Thu Jan 11, 2007 9:46 pm Post subject:
Hello Nicolas,
toutencarton wrote:
Thank you for all your answers.
Actually, the process inventory I am working on is the inventory of what exists, ITIL compliant or not.
Only in a later step, I will choose priorities in processes to improve and move the existing to ITIL.
It appears you are in the midst of a Process or discipline called "Process Management", which is not, itself, a discipline that is formally covered by ITIL but which is critical to each and every enterprise as an operational process. In short...
If managing all your Assets correctly is Asset Management... and
If managing all your Incidents correctly is Incident Management... and
Etc... Then we can assume that...
Managing all of your Processes correctly is Process Management
Again Process Management is not an ITIL discipline but something that really comes from SEI's CMMI framework. However, I believe based on our experiences that it is one of the most critical disciplines to implement and manage properly, as your enterprise starts to grow and scale beyond a small business.
While this list doesn't cover all "operational processes", you may want to look at: TraverseIT.com (or TraverseIT. com/ it_opts.html in the event that the real link gets scrubbed from the post) for a list of many that you can start with. The actual list of operational processes that you use to run yourself like a company is very large.
Quote:
My great question is : as it is impossible to make everyone learn the procedures (in a environment made of people most interested in technology than in company organisation), how to make something easy to use from high level processes to very technical work instruction (assuming that time is an essential factor in case of incident) ?
Well, the first thing I recommend is that you have a centralized place for them to go to find exactly what they need:
Your inventory of Processes
Your inventory of Policies
Your inventory of Products
Your inventory of People
Your inventory of Organziations
Etc.
Finding what you need, when you need it, easily and in the form you want to see it is one absolutely critical factor to success.
Another thing that helps with success is the clarity and purpose of the process(es) you implement. If your talking about "Build Management", which is the process by which you manage all of your Asset Builds, (SW, HW, Widgets, etc.), then knowing why it's important to have standard, repeatable, determinable, and high quality builds helps the people doing the building understand why following the process is important.
Another thing that helps is the understanding of upstream and downstream dependencies. If a person working in a given process area understands whats coming to them from upstream to (what, how, why, when, etc.) them and they understand what downstream dependencies need from them (what, how, why, when, where, etc.), then understanding why they need to do what they do becomes clearer and more precise to them. People tend to like "tangible". The more tangible the reasons, the higher the probability of acceptance.
Anyhow, I hope this helps.
Best Regards,
Frank _________________ [Edited by Admin to remove link]
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
