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.
