Reporting Limitations?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎02-27-2013 06:30 AM
Hey everyone, looking to get some outside opinions here. When it comes to our SLA reporting, we have found our reporting capabilties are limited within the SN platform. So what we have been doing, is exporting and doing all of our manipulation with some macros within excel. From there we use the data within an Xcelcius dashboard. Heres me question...
We have been looking to develop our own stand-alone web reporting application in C# using the .NET framework. We had a talk we a SN now rep and she mentioned everything we are doing can probably be accomplished with the creation of metrics and report on those. I wasnt really in agreement. Based on what our leadership has set and what they wish to see from these reports, we need to do alot of date calculation and manipulation in order to have the correct data to report on. For example, aging buckets (6 different ones) are a main focus and I dont see how metrics could accomplish this. We also have a data issue within SN becuase our SAP HR folks will not clean their data up and naturally the information in AD which we feed to SN is not correct. We need to deal with bad-data quality once we have exported. Basically we break the reports up into two high levels (INC & GREQ). GREQ is our own special record which we have created within the SN system. From there, each section has the following...
Open - by different views
Closed - by different views
Trend - Open/Closed/New, Average Aging, Greater than 120 Days
Non-Compliance - by different views
The same thing is replicated for our GREQ's (whcih are not SLA bound, by rather by a due date that is set by the user)
Correct me if I am wrong, but I was under the impression that metrics were a way to track information about a record at certain points in time. Maybe I am confused, but I dont see how that would help us? How would the creation of the aging buckets happen and rendered into a chart? Thats also another thing that concerns me, sure maybe some of these different reporting views could be created, but how many different reports are going to need to be created? Seems like a lot to me. The good thing with the Xcelcius tool is it is very interactive and looks quite nice actually. A lot more functionality there in my opinion.
I just want other peoples opinions. Maybe I am wrong and this can all be done. If thats the case, I am not partial to any approach. It would be great to stay as close to OOB as possible (since thats the culture here).
Thanks for the long read.
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-05-2013 11:25 AM
My policy with ServiceNow implementations is to do as many reports in ServiceNow as possible. Those reports are easily accessible to users and easy to make. There are limitations in the ServiceNow reports when it comes to calculated fields, data groupings, parameterized reports, dates, and other complex reporting. If there is a significant amount of these types of reports needed, then I use an external reporting tool with the SN ODBC driver to create these additional reports.
In ServiceNow it is true that you can make custom charts and views to make these complex reports as well. However these custom reports sometimes require a significant amount of jelly and javascript knowledge to maintain after I leave. Also just building in an external reporting tool is quicker in cases.
I think you are using the right method. Create as many as you can in ServiceNow, and the complex reports in your external reporting tool. In future versions of ServiceNow, reporting maybe stronger, but for now this is my opinion.
Mike