OTRS is known as best-of-breed in open source incident management systems. Since quite some time, OTRS made its product ITIL V3 compliant. Means: It also comes with a change management module.
At work we use a complex and extremely user-unfriedly software. This brought me to the idea to test the OTRS change management module in order to propose OTRS as a replacement for the currently used software for the Change- Incident- and Problem Management.
Incident- and Change Management integration
I was surprised how easy it is to change the ITIL type of a ticket from “Incident” to “RfC”. As soon as the ticket is of type RfC a new button appears: Create Change. The ticket gets automatically linked to the new change. Creating the change looks strait forward. Assigning people to the CAB was also quite easy. You also can generate a CAB-template with a few clicks. So far so good…
Where the trouble begins
The newly created change is now of status “Requested”. Whats next? Right! to approve it! But how? OTRS is using something they call “state engine”. You need to add “Workorders” and “Conditions” to your change. For a standard-change I made a template with a condition “If workorder-title=Standard-Change, set change to status approved“. In this case you just link a “workorder” to the change, call it “Standard-Change” and your change will be approved. Next Condition is to set the state of the change to “successful” when the “Workorder” is of state closed. At the end of the day three tasks and approx. 20 clicks for a simple standard-change. Not too bad.
Where it goes to insanity
Non-Standard-Changes usually have a CAB (Change Advisory Board). This makes sense because the change-requester usually does mot have the full overview about complex systems and services. Now, as I wrote further up, it is quite easy to create and assign a CAB to a change. So how works the process? Usually every single member of the CAB must approve a particular change. It should be easy to send all the CAB-Members a Email with a link where they can approve or reject the change. In OTRS this is a huge and very complex task.
The change manager or change creator has to create a “workworder” of type “Approval” for every single CAB-Member AND create a condition to it. If you plan a huge change such as upgrading Powerlines in a Datacenter, the CAB can grow to dozens of people. I tried with two CAB members and it was costing me about 20 minutes to create it (Without proper texts in the change and workorders). Think about a 20-people CAB. It will take hours just to create a proper change! This is so nuts!
Why are all ITIL compliant change mangement tools just crap?
ITIL processes are quite simple. One should think it is also easy to implement them in software and in companies. Wrong! The mind of People with ITIL-Roles such as “Change Manager”, “Problem Manager”, “Availability Manager” and “you-name-it-manager” works obviously different. It looks like they add as much complexity as possible even to every simple task. Obviously the ITIL-compliant software developers think the same way or got the orders to do so. I think this is the root cause of the completely unusable software OTRS::ITSM Changemanagement and others such as Remedy and Peregrine.
Conclusion
As there is no easy usable software on the market, companies should either write its own software or getting the less-crappiest software around. At the end of the day I’m tired of this and I’m not going to test similar software again.
Hello Luc,
as you said, ITIL processes are quite simple, at least sometimes. 🙂
Regarding your example, with 20 people in a CAB, the ways this was meant in OTRS::ITSM is that you can create one approval workorder and assign it to the change manager. The CAB would meet regularly (in person, telephone, etc..) and decide and advise on upcoming changes.
The decision if the change is approved or not, can then be made by the change manager based on the CABs advise, so there is no need for every CAB member to have their own approval workorder.
In my opinion such a complex use case which requires 20 people to approve something sounds a little complicated in real life, but who knows. There are a lot of different use cases for almost everything, and it is hard to have them all considered in one product.
If you are missing some features, or if you have feedback or ideas, I would really like to invite you to contribute to the further development and improvement of OTRS::ITSM.
You can get involved either by discussions on our mailing list, by filing enhancement bug reports with your ideas of improvements or missing features, or contact the OTRS AG for professional consulting, support or development services.
((enjoy))
Udo
http://www.otrs.org/
Dear Udo,
I was surprised about your feedback and I’m glad to get feedback from OTRS.
First I need to admit, I’m not a ITIL specialist, I’m a Linux System Engineer.
I’m working for a IT-outsourcing department for a huge company which is ITIL driven. OTRS was (still is) my big hope to be able to propose to replace the currently used crappy CM-Tool with something better, in the best case with a open source tool.
I hope you get the point that I really like (and still like) OTRS’ incident management and stuff. But I was really frustrated when I experienced that the change management was not on the same quality and user-friendlyness I have previously experienced with OTRS.
My example of a 20 person CAB and powerline upgrade was a bit too much, for such changes indeed a physical CAB is best practice. There is a config option to set which allows persons to manually set a change to a particular state, which is great for physical CAB’s. Nevertheless companies tend to have “virtual” or lets say “electronic” CABs instead of “real” meetings. At the moment, OTRS’ change management is unfortunately completely useless for such “virtual” CAB’s.
From my point of view, CAB members show get a email with a link where they can approve or reject a change with a simple textbox to insert the reason why.
In meantime I spoke with our ITIL responsible person, OTRS is on the radar.
Since my Perl knowledge is rater poor, getting time for helping with development even more complicated… I promise to have a look at it if time is allowing it.
Have fun!
Luc