Purchase Order & Contract Management Show Stoppers
Generally speaking (I have read posts of others who have voiced similar concerns), there are some fundemental principles that have to be adhered to in order one to utilize ServiceDesk's purchase order system in a commercial environment. It is critical that there are some immediate fixes instituted so that this software product meets the general needs of all who utilizes POs for their asset authorization process (this comes down to security):
ServiceDesk Purchase Orders
1) You have to have a Purchase Order history tab that shows exactly what was done in the purchase order creation and approval process (auditors typically look at this type of information, not having this information is very bad when talking about millions of dollars a year in expendatures). Email submissions for approval, the approvals and rejections themselves between requestor, originator and signing authority should be captured as "conversations" within the PO history tab just like a ticket request.
2) Purchasing authority has to be a manditory drop down field with multiple choices available. In most cases, the purchasing authority is not a technician, in fact, they usually are a Controller, Director, VP, CFO or higher who are not technical in nature. The proper authorization process should not require to burn a full license in order for an individual to put their approval on a PO. This has to be a simple process for an executuive to execute. There should be a way in which the "submit for approval" goes to the purchase authority's email who in turn can log into the system as a "requester with PO authority" to only see the PO submitted for approval to be either rejected or approved. Better yet, a simple reply from the purchase authority's email with the subject line of approved should be sufficient to automatically approve the PO. The contents of this email should be captured just like a conversation within a normal ticket (see #1).
3) Purchasing authority has to be limited within the roles section so that not every technician who has the ability to create a PO can then turn around and approve the very same PO that they just created. In addition, without #1 you now have no visiblity over who approved what. You also need to be able to run a report in the reports section that shows who requested the PO (see #4), who originated the PO and who approved the PO.
4) You need the ability to have a "requester" for the PO. This would be the person that is requesting the assets (not the technician creating the PO). The originator would be the "technician" who would actually create the PO. The technician is the control point for the PO process. Most approving authorities need to be able to view who the requester is, what are they requesting, and why.
5) You have to have an "additional fields" configuration (just like asset additional fields or requester additional fields) so that you can add specific PO information that is generic to your business. For example, cost center or general ledger code.
6) A printed PO (print preview) has to have the approval status listed!
ServiceDesk Contract Management
It is critical that contract management has the following three items to be a complete solution:
1) Customizable "additional fields" (Please see Purchase Order request #5). This would be most helpful to capture information such as license key's, links to other document repositories (such as Documentum - WebXtender), etc.
2) You need to be able to send an email for notification to anyone as opposed to just sending notification to "technicians." Many individuals who fall within Accounts Payable or Compliance Management would want to get these types of notifications. These would be non-technicians who would never need to get on servicedesk other than to receive this type of notification.
3) You need to inject an escalation process within the contract notifications. There needs to be a default notification date (say 90 days before the expiration of a contract), with then the ability to notifiy individuals again at 60 days, then again at 30 days, etc.
Reporting needs to be able to tie into all of the above recommendations in order to be a comprehensive solution. Please take these suggestions into serious consideration. From our perspective, these outstanding items currently are creating road blocks on our operations. We would be much more inclinded to purchase more licensing immediately if we had these capabilities available now within the current ServiceDesk software version.
ServiceDesk Purchase Orders
1) You have to have a Purchase Order history tab that shows exactly what was done in the purchase order creation and approval process (auditors typically look at this type of information, not having this information is very bad when talking about millions of dollars a year in expendatures). Email submissions for approval, the approvals and rejections themselves between requestor, originator and signing authority should be captured as "conversations" within the PO history tab just like a ticket request.
2) Purchasing authority has to be a manditory drop down field with multiple choices available. In most cases, the purchasing authority is not a technician, in fact, they usually are a Controller, Director, VP, CFO or higher who are not technical in nature. The proper authorization process should not require to burn a full license in order for an individual to put their approval on a PO. This has to be a simple process for an executuive to execute. There should be a way in which the "submit for approval" goes to the purchase authority's email who in turn can log into the system as a "requester with PO authority" to only see the PO submitted for approval to be either rejected or approved. Better yet, a simple reply from the purchase authority's email with the subject line of approved should be sufficient to automatically approve the PO. The contents of this email should be captured just like a conversation within a normal ticket (see #1).
3) Purchasing authority has to be limited within the roles section so that not every technician who has the ability to create a PO can then turn around and approve the very same PO that they just created. In addition, without #1 you now have no visiblity over who approved what. You also need to be able to run a report in the reports section that shows who requested the PO (see #4), who originated the PO and who approved the PO.
4) You need the ability to have a "requester" for the PO. This would be the person that is requesting the assets (not the technician creating the PO). The originator would be the "technician" who would actually create the PO. The technician is the control point for the PO process. Most approving authorities need to be able to view who the requester is, what are they requesting, and why.
5) You have to have an "additional fields" configuration (just like asset additional fields or requester additional fields) so that you can add specific PO information that is generic to your business. For example, cost center or general ledger code.
6) A printed PO (print preview) has to have the approval status listed!
ServiceDesk Contract Management
It is critical that contract management has the following three items to be a complete solution:
1) Customizable "additional fields" (Please see Purchase Order request #5). This would be most helpful to capture information such as license key's, links to other document repositories (such as Documentum - WebXtender), etc.
2) You need to be able to send an email for notification to anyone as opposed to just sending notification to "technicians." Many individuals who fall within Accounts Payable or Compliance Management would want to get these types of notifications. These would be non-technicians who would never need to get on servicedesk other than to receive this type of notification.
3) You need to inject an escalation process within the contract notifications. There needs to be a default notification date (say 90 days before the expiration of a contract), with then the ability to notifiy individuals again at 60 days, then again at 30 days, etc.
Reporting needs to be able to tie into all of the above recommendations in order to be a comprehensive solution. Please take these suggestions into serious consideration. From our perspective, these outstanding items currently are creating road blocks on our operations. We would be much more inclinded to purchase more licensing immediately if we had these capabilities available now within the current ServiceDesk software version.