12 Replies Latest reply on Nov 10, 2016 8:11 PM by [email protected]

    Incident categorization


      We are just beginning the process of implementing HEAT Service Management in our organization of approximately 11,000 users in 26 different departments.  In looking at the OOTB Incident screen,  there are two levels of categorization - Service and Category.   Our current service catalog is relatively high level and there are many request offerings under each service.  I cannot see how to effectively categorize incidents for both optimal routing and reporting without adding a third field for product/service...   I am interested in knowing how others have configured  incident categorization to meet their needs.  

        • 1. Re: Incident categorization
          florian1 Expert

          Hi Mary,


          we have done various things to make our Incident Management (and categorization) more effective.

          Two of them are key for us:


          1) added a "responsible team" field to our categorization.

          This helps us to easily identify and assign Incidents to responsible teams.


          For example, when you have "SAP" as a service, you might have the following categories:

          - FI/CO (Financial Accounting)

          - TR (Travel Management)

          - RE (Real Estate)

          - [...]


          And for each category we have a responsible team which is automatically populated (based on Service -> Category).

          It looks like this:

          When we create a task, this team is set as the default value.


          2) added mandatory questionnaires bound to categories (IncidentDetail.*) to always get the information we need and help our 2nd level to troubleshoot faster.

              E.g. if a VPN connection is not working, you might always want to ask the following:

              - customer's external IP..

              - did it ever work before..

              - can you do a DNS query..

              - [...]



          ..but more important (a little off topic): Try to avoid Incidents or at least reduce the time needed for analysts to resolve it.


          1) Use your known errors to resolve similar Incidents & always create Knowledge articles if needed

              - this will help you a lot with frequently asked questions..


          2) Teach your customers the advantage of using the Self Service

              - use Service Request Templates (and try to automate many of them)


          3) Define and track KPIs to make your Incident management more effective

              - wrongly categorized Incidents

              - Incidents taking longer than 1 week (find and eliminate root causes)

              - recurring Incidents

              - First Call resolutions


          4) use Event Management to proactively prevent Incidents

              - Use Nagios, Splunk or whatever to monitor your Services.

              - Use TestCases to simulate User Interactions (AutoIT, Selenium, WebInject etc.)


          5) Populate and use your CMDB

             - If a single user has different issues it might be related to his asset..

             - if an error occurs on many clients after a specific Software package was installed, it might be the package itself..

             - [...]





          • 2. Re: Incident categorization



            I appreciate your reply and I can see how both of the items you mention would be helpful in the management of incidents.  We very much want to  use this tool to drive to a more effective process.  Does this categorization give you the level of reporting you need?   Do you capture the type of incident like "error message", "Performance issue" , "Connectivity" etc.?  And is that level necessary to narrow down applicable knowledge?



            • 3. Re: Incident categorization
              florian1 Expert

              Does this categorization give you the level of reporting you need? 

              Well, mostly. At least it's a good start to have a high-level overview of your Service Portfolio and its potential issues.

              We still do have (and plan to have) additional (low-level) reports/analysis in regards of

              - the bottlenecks/FAQs per Incident Category

              - customer and analyst feedbacks

              - tasks reassigned between teams (do we need more categories? is it the right team?)

              - categories with most of the Incidents (do we have to narrow it down?)

              etc. to see if we can do any better in categorization.


              Do you capture the type of incident like "error message", "Performance issue" , "Connectivity" etc.?

              We capture the main cause codes (wrong installation / Bug / consulting etc.). Try not going into too much detail to have reliable values.

              Very handy to get a feeling for where you should put your optimization efforts in at first sight.


              And is that level necessary to narrow down applicable knowledge?

              No, not neccessarily.

              At least we try to keep it simple to get our analysts into writing knowledge articles and customers reading these articles (and effectively resolving their own Incidents).

              Knowledge should be made public to everyone if possible.

              • 4. Re: Incident categorization
                ccrispin Apprentice

                Hey Florian

                I was just wondering if you could expand on how you put in place

                2. ---added mandatory questionnaires bound to categories (IncidentDetail.*) to always get the information we need and help our 2nd level to troubleshoot faster.


                This sounds great as I have some 2nd level techs who complain that the first level never get the required detail. If I can add some prompt type questions based on the category this could help alleviate some of the complaints


                thanks in advance

                • 5. Re: Incident categorization
                  florian1 Expert

                  Hi Charles,


                  out of the box, there is a relationship called "IncidentContainsIncidentDetail" which refers to the business object "IncidentDetail#".

                  By using a group object type selector bound to the category, the member is automatically selected.


                  I'll give you an example:

                  You always want to know the System and the user ID each and every time the category "Account Lockout" is chosen.


                  1) Add a child panel to the form view (e.g. "IncidentDetail").

                  2)  Add & link the category "Account Lockout" to a Service.

                  3) Create a new Incident, select the Service from 2). You will see an additional tab asking you for further information.



                  The form you see in 3) can be found in the respective member object:


                  To make fields mandatory, you can add a calculation rule like this:





                  2 of 2 people found this helpful
                  • 6. Re: Incident categorization
                    daveb1 Apprentice


                    I like this technique, but how does "By using a group object type selector bound to the category, the member is automatically selected." work?  I see where the type selector 'Category' is entered in the relationship, but how does the incident category of 'Account Lockout' indicate that the IncidentDetail group type should use the 'AccountLockout' type?  The names are similar but the space makes it different.  Is there a mapping?




                    • 7. Re: Incident categorization
                      florian1 Expert

                      Currently, only spaces within the category are removed to get a mapping.

                      I hope this will be extended soon by other chars like slashes etc.


                      See KB article 12078:

                      You can use spaces when creating the New Category and those spaces will be taken out when HEAT searches for the extension object suffix.  For example “Test Test” would find the suffix “TestTest”.




                      1 of 1 people found this helpful
                      • 8. Re: Incident categorization
                        florian1 Expert

                        To complete this, the mapping is done right here in the "ObjectViewDetailTab.js":


                            getBOTypeBySubtypeField: function() {
                                var masterData = this.parentFormView.getMainFormCurrentData();
                                var type = Ext.Frs.DataModel.getValue(masterData, this.parentFormView.getMainObjectId(), this.autoTypeDataIndex);
                                formName = this.formMap[type];
                                if (!formName) {
                                    //in case its only the last part
                                    type = this.objectType + type;
                                    formName = this.formMap[type];
                                if (!formName) {
                                    //in case there are spaces
                                    type = type.replace(' ', '');
                                    formName = this.formMap[type];
                                return (formName) ? type : null;
                        • 9. Re: Incident categorization
                          mike171 Apprentice

                          We implemented a similar method to Florian.


                          For some background, we are a food manufacturing company with ~8,000 employee's. Supporting a Home Office, 17 Domestic and 13 International manufacturing locations.


                          The final subcategory drives the end team assignments

                          Select the Service (examples: Desktop Application Services, HR and Payroll Services, Supply Chain Management Services)

                          This filters down the Category (For us these are usually use systems or application, depending on the service)

                          Then we have Subcategory (We don't use these on all of our categories so it's not a required field but we have a default value (All Categories) for most. We use this for subsystems, specific forms, and geographic regions)

                          The Subcategory drives the Team assignment as I said earlier

                          Here are a few examples


                          (left) RMCS is a plant warehouse system, BF consumption is a specific screen.

                          (Right) PL/SQL Developer is the software, ISPS-N is our regional local support team


                          (Left)WMS - Warehouse Management System (Which has many parts, supported by different teams), WMS Inventory- Specific software

                          (Right) Just some example Categories for Finance Services

                          • 10. Re: Incident categorization

                            Hi Florian,


                            I followed your instructions all the way down to making the fields mandatory. I'm not getting how your example of the calculation rule would make them mandatory. Can you provide more detail please? Everything else works beautifully. I just need this bit of help.

                            • 11. Re: Incident categorization
                              florian1 Expert

                              Hi Julie,


                              sorrry, I think I've missed the important point here..

                              I am only using this calculation rule as some kind of variable to determine if a field needs to be filled out. As a result, HEAT only needs to evaluate the expression once (instead of n times depending on your fields).


                              You will still have to set the "required" option either on forms level or as a "Required" business rule.

                              I prefer to set it on forms level because we sometimes have field dependencies (XTN_isRequired is the field populated by the calculation rule):


                              • 12. Re: Incident categorization
                                a.mossop@qut.edu.au Apprentice

                                Hi Mary,


                                The first thing I will say (and I cannot stress this enough)...before you start to design or even think of categorisations, firstly identify what your organisation has regarding reporting requirements.  Then build your incident classification/categorisation around that, it will save you time, heartache and headaches for your reporting person.  Incidents themselves don't need to be classified in order to have someone work on them, those fields are there purely for reporting purposes.


                                To answer your question though, we have three levels of categorisation (which has been designed around how we do classification)

                                1) Service (which is really should be called "Service Portfolio") eg. Communication and Collaboration, Identify and Access, Learning & Teaching Support etc

                                2) Enterprise Application - i.e. the particular system in that portfolio which the issue is happening with

                                3) Category - a board fault category which best describes what the issue is about