10 Steps to Process Design Preparation for OTRS Process Management.

Shawn Beasley16. Jan 2020 | Best PracticesMiscellaneous

Disclaimer:

The practical examples presented in our technical blog (blog.otrs.com) and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept. 

We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.

In life, preparation is everything. When preparing to automate (orchestrate) tasks in OTRS, the main work is not in programming the process module to do what you desire, but it is in the preparation. With good preparation, designing processes to use with OTRS is a breeze. Here are the 10 Steps to Process Design Preparation for OTRS Process Management.

Let’s take a Service Desk Incident Process as an example.

  1. Identify activities of the process.
    These should not be TASKS like “Set queue to 2nd Level,” but should be Create Record, Categorize Incident, Prioritize Incident, Analyze Symptom, …
  2. Identify data collected by the process.
    Request Type (Tickets)
    Service Level Agreement (Time to work on ticket)
    Service Level (Criticality)
  3. Identify the workflow of activities.
    What is done first, second, third?
  4. Identify useful dialogs for each activity to help collect or record the data.
  5. Identify triggers for optional and immediate advancement to the next activity (i.e Escalate to 2nd Level).
  6. Determine which data should be saved as process data for use in templates (i.e. Handover texts).
    Description
    Initial analysis
    Suggested workaround
    Workaround results
    Confirmation that the knowledge base was consulted
    Verification of the system version
    Attached log files
  7. Identify escalation paths (i.e. Escalate to 2nd tier after workaround failure).
    Do we have multiple escalation paths?
  8. Set workflow requirements.
    Consult Level 2 or other departments where escalation is possible to gather their requirements.
  9. Identify loop-back possibilities.
    Under which circumstances can requests boomerang and why?
  10. Draw the process ( i.e. with a tool like https://bpmn.io).

Your email address will not be published. Required fields are marked *