Hi Kathy,
Gather your customer's requirements, document them and agree them. I itemise the functional requirements into a Requirements Catalog. I then map the catalog items, which are my business process activities, into technical solutions which becomes the technical specification. Sometimes I actually build parts of the application on my dev server while I am writing the tech spec. It helps me build a more accurate technical specification. It seems weird, writing the application before the tech spec but it works! Build. Test, test, test, which is everyone's favourite part :)
If you understand your understand your customer's requirements, you will be able to build an application which matches their business process. I like to think that you can lock down most of the application fields until they are needed. It reduces user error and guides the users through the application and process. Display help text and pop-up boxes for the users telling them where they are and what functionality is available. The status field plays a big role in most workflow apps. I usually lock that down and let the workflow change the value. For example, there are certain conditions that need to be met when an incident record moves from New to Assigned to WIP to Resolved to Closed. You have to ask yourself, can I go from New to WIP? What information is required? These rules should be agreed with your customer up front. Also, think of the inverse situation as well. What should happen when the condition is not met?.
This may not have answered your question exactly, but I do find that all of this up front work pays off at the end.
BTW - ARS v7 has some great built in auditing functionality. Just switch it on and you have immediate field auditing in place.
Michael.
Michael Worts
Remedy Specialist
IGS, Business Consulting Services
ITIL Service Manager Certified
Tel: +44 (0)1962 822273 Mob: +44 (0)7801 755346 Internet: [EMAIL PROTECTED]
| Robert Molenda <[EMAIL PROTECTED]>
Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 09/11/2006 01:19
|
|
**
As I have to remind seemingly continuously my requesters… Business Requirements can be translated into Implementation Specifications, which can then be utilized to Build the System.
It sounds like you are, as I also say all the time, pushing the cart on the road with leaving the horse in the barn.
It is nice to “Window Shop”, and believe me, we do this on a yearly basis. We get selected tool vendors in and ask them to show us “their system” while we take notes and ideas.
I have seen some really “Pretty” UI designs that simply were not functional.
Conversely, I have seen very functional UI, that is not User Friendly.
Some simple things in UI Design drive me batty at times, and here is an example which I had to believe it or not, fight with the customer (HPD Manager) to understand.
Customer Requester Console for Incident does not have any “Urgency” field (the ITSM fields are Priority (internal) & Urgency(Customer))
This field has been disabled in all work-flow related decisions, reporting, etc.
The Incident Edit window still had the field present!
AARRUUGGHH!!!!
So start with the Customers Business Processes / Requirements (Processes, KPI Reporting, Notifications, SLA, …) and then start looking around doing the “Window Shopping” The majority of the time, the customer is quite happy with a nice functional car rather than a Ferrari which is high maintenance and breaks down a lot. (no I am not knocking Ferrari!!!) They need 30 fields for Incident Management, give them 30 fields, not 29 or 31. As much sense as it might make to you, it might not make sense to them. But that is what the Implementation Specifications can be reviewed for J
And Yes, when it comes to actual system design, I agree with Joe’s comments below.
Thanks-n-advance;
HDT Platform Incident
/ Problem Manager & Architect
Robert Molenda
IT OS PA
Tel: +1
408 501 6310
Fax: +1
408 501 2410
Mobile: +1
408 472 8097
[EMAIL PROTECTED]
Quality begins with your actions.
From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe DeSouza
Sent: Wednesday, November 08, 2006 2:49 PM
To: [email protected]
Subject: Re: Help Desk Designs
Performance should be on top of all priorities when you are rolling out your application to an external customer/user. Internal users might have to live with average performance as they are literally 'forced' to use your application but not the external user.. External users would not spend more than a few seconds if they have to, to log on to a system for example to identify themselves, see their home page and click around till they are able to submit or browse for existing tickets..
So I would pay most amount of attention to that, and secondly as you pointed out if things dont 'look' pleasing enough, they are hardly willing to use it especially inside of business hours - they might just call instead of using the web..
Pay a lot of attention to queries in your workflow to make sure they are optimized, index fields that require them even though the out of the box application might not have indexes on certain searches if you feel that creating that index will help the queries both defined in the workflow as well as possible queries your user might run..
Hope this helps..
Joe D'Souza
Remedy Developer / Consultant,
Shyle Networks,
New Jersey.
----- Original Message ----
From: Kathy Morris <[EMAIL PROTECTED]>
To: [email protected]
Sent: Wednesday, November 8, 2006 4:10:08 PM
Subject: Help Desk Designs
**
Hi,
I am redesigning our help desk application. Are there any utilities or design ideas posted on the web to which give us a fresh look at redesigning say the Help Desk application? Any def files with auditing ideas?
It would be great if there were because the better the interface looks the more clients like the application... . just my opinion (of course functionality is first priority).
__20060125_______________________This posting was submitted with HTML in it___
Access over 1 million songs - Yahoo! Music Unlimited.
__20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
__20060125_______________________This posting was submitted with HTML in it___
