Blogging Daily

To get into the habit, I'm making a committment to myself to blog daily for thirty days. Every day, I will create at least a paragraph or two of original content. For example, I just posted a cool python recipe I found on the net to my tumblr, but that won't count. This entry, on the other hand, does.

Today I'm completing my RT installation. We're installing RT to help us manage the support process as well as to support the design request workflow and interactions with service providers and consumers.  I'm finding it a little difficult to focus, and the docs seem to lack polish which is probably more discouraging than warranted.

The interesting part of this project is the process automation aspect.

1. Our customers send us requests through any one of a variety of means - email, fax, file upload and telephone support are all valid options (although the phone option is a rare special case). 
2. Once the order is received it is examined and 'cleaned' - a preprocessing step we perform to ensure requests sent to service providers meet a minimum quality and completeness standard. It's possible at this step cannot be completed without contacting the submitter to gather additional information, or clarify some ambiguity. 
3. Cleaned orders are then submitted to a service provider who fulfills that order, returning a completed 'design package'. During the course of creating the package, the service provider may have questions that need clarification as well - these questions are passed to the submitter and processing will halt until the proper clarification is recieved.
4. Orders completed by the service provider are validated by our customer service staff prior to delievery back to the requestor. Failed validation here can result in additional clarification interactions with the service provider as well.
5. Finally the verified, completed order is returned to the submittor for final acceptance. The existence of errors in the design will trigger a correction cycle where the service provider will be required to address the issues and return an updated design package.

These steps are in fact a simplification of the actual process, and there are points of flexbility in the process that I don't bother to note, but there are some common requirements that apply across all of the possible scenarios -

• Traceability -  every significant action in the lifecycle of an order must be logged.
  
• Visibility - it should be easy to see the current status of all orders, to access their history, and to be notified of changes in an orders status. This visibility should be available to all stakeholders of a particular issue (e.g. submitted-by for submitters, serviced-by for service-providers, and by account for service-reps)
  
• Accountability - the system should provide a basis for measuring performance, and helping stakeholders to meet committed goals - e.g. 24 or 48 hour turnaround times.
  
• Flexibility - the system should not lock us into a particular workflow, or prevent us from modifying the workflow unreasonably. For example, workflows will vary as the process matures, and workflows may differ based on submitter or service provider (or the two combined).
  

Our initial plan was to build this workflow into the system, but on second thought this didn't seem to be a great use of our time and resources.  The advantage of going with something like RT is that it has most of what we need out of the box. The disadvantages are yet to be cataloged (which is itself a disadvatage) but will probably include some necessary integration pain, and possible limitations related to integration.

Wish me luck - I'm off!