Fault! Report It Through Workflow!

Accuracy and swiftness are indispensable in fault publication. Especially, how the time can be shortened between occurrence and primary announcement. Presentation format of "Fault report" may be different depending on businesses (industries), but to create statement it is almost the same process (Workflow)

• Web Business (Web Services in wide sense)
• Data center Business
• SaaS Business
• Communication Business
• Transportation Authority
  etc.

Furthermore, it is apt to forget, it is most important to closely analyze on gathered information of those fault. Not only improve business processes in case of fault occurrence, we want to analysis periodically of support history such as time reported.

<Tasks>
1. Fault Detection Report, 2. Assignment, 3a. Primary Statement, 3b. Primary Report (application), 3c. Primary Report (Infrastructure), 4a. Scheduled Announcement Update,
4b. Scheduled Recovery Report (application), 4c. Scheduled Recovery Report (Infrastructure), 5. Check Primary Statement, 6. Check Recovery Completed

There are countless 'Tasks that can't put into order' (ad hoc task groups) in Fault Support. In particular, it is hard to make up sharing procedure or route about information such as "additional information about fault" and "complaints from outside". In such business process, you better define only 'Backbone task', not sticking to the definition of smaller tasks.
By the way, if you experience this kind of ad hoc communication, function of In-house micro blogging would be effective. In-house micro blogging feature which linked to Workflow is equipped as standard in Questetra BPM Suite. Give it a try!

[Fault Publication [2. Assignment] screen]

[Email Setting screen]

• A Workflow That Helps Teamwork in a Time of Crisis (2010-11-06)
• The Way Multilingual Translation Should Be (2011-06-20)

• Transmiting_fault_information