Survival Recovery System Draft Design

 

Order Now! (1 wk delivery)

Visit the Beta Site!
Contact Us
 
Safe! (Pure Active Server Page Code)

Overview:

 

 

 

The "Survival Recovery System" will revolutionize email communication and slow down spam and virus vulnerability.  SRS will provide a centralized communication collaboration system where all corporate workflow can be done.

 

People join the SRS and are allowed to post messages to channels.  The SRS operates on the assumption that the “people have the answers”.  Center leader are promoted from the community and control the “workflow” of the message.  Center leaders are trusted community members and are expected to have integrity and promote the general welfare of the community.

 

As the message advances through time: all the work decision history is stored, auxilliary attachments are connected to the message, drill down into feedback between channel groups is possible, and all channel group comments are embedded in the message.

 

Keith Ogden is quoted to say, "we must be able to measure time performance" between channel groups.   The message structure can be analyzed to extract time and quality metrics.   Keith believes the SRS will become a CMM business intelligence tool.   Its possible to built ghant charts for the time lines stored in the message. 

 

Think about the message as a piece of work on an assembly line.  At any point, a controller, in the SRS can see the progress of the work message.   Because the message is associated with a priority status it will be possible to see which agencies are being over run with critical messages.

 

The most powerful feature of the tool will be the capability to correspond back and forth from the SRS to anyone in the world and requesting a response, while maintaining all information historical information within the confines of the SRS.   No information is lost in a correspondence of emails.

 

As companies start to rely more and more on information, a centralized approach to information management only makes sense.

 

Dynamic Form

 

This is the setup form for the dynamic form. 

 

The user will be able to add or remove an unlimited number of fields on the data form. 

 

Step 1:  The user creates a form and associates the it with a channel classification

Step 2:  The user enters in field information, such as, sort position, field type, field name, field length, and field description.   If the field type is a list box, the user will be able to enter in list box items.

Step 3:  The dynamic form will then generate the input html form to be stored in the database and an output xsl to transform the inputted xml structure into output readable html.

 

The form transform component will take the definition and build an html form to be stored in the database.  The html form will receive input from the form and transform it into a message xml structure stored in the central database.  

 

Workflow manages the channels of the Message and ensures the correct people are in the loop to work the message.  The channels are represented as code numbers extending from point to another point, as demonstrated in the following diagram. 

 

For example, channels code 21 is the enter channel into the command center where it receives a priorty number.  The priority number inhibits the level of responsiveness.  Suppose, we have a structure of channels codes as follows: (22) represents Accounts Payable and (23) represents Inventory and (24) represents the controller and (25) represents the SRC command central CEO.  Suppose individual X submits a message.  Individual X enters in information requests from the dynamic form.   Individual Xs data entered information will be a part of the message structure.  Also, some resource information about individual X will be a part of the message structure.

 

In this case, Accounts Payable (22) receives the incoming message.  Members in the groups (22) can add notes, documents, or request feedback from various external groups through email collaboration.  Now the message contains notes, uploaded documents, feedback information, and decision information from both groups.  Only the center leader of group 22 can promote the message on to the Controller.  The route of promotion will depend on the structure of the company’s workflow steps.  The Controller group can review the notes, decisions, feedback and promote it back for more rework or promote it on to the SRS Center CEO.

 

One and only one group can manage a message, at a time.  This is the controller group.  The controller group will be able to cross talk with other groups while taking exclusive ownership of the message.  Ownership transfers after the center leader promotes the message.  So, if (22) becomes the controller group, it can cross talk with anyone about collaboration information.  Individuals receiving requests for information will response through a public SRS response web page.

 

At command center, messages can be queried and displayed by entering a channel.  The channels queues will need to be completely mapped out, so movement occurs in the prearrange pipe.  This mapping out should be a part of the Emergency Plan checklist.

 

People and Channels

 

People are associated to a channels number.  When new messages arrive in the channel individuals associated with the channel are notified.

 

Decisions

 

The important aspect of the message flow is that it is treat like an assembly line

product.  The message must work through the system.   It will show all the feedback information and decisions made.    Decisions are (Yes, No, and Hold) rules.

 

In some cases, before promotion acceptance can occur, a series of expert questions must be answered.   Depending on the results of the logic tree, other channels may be recommended, by the system.   The controller group can make the choice to accept the channel advice or ignore it.   A history of the channels will be appended to the message.   Additionally, one or more documents can be attached to the message.

 

 

Channels

 

Features of a Channel

 

For example, if a message involved accounting, the message may be need to route to in a formal promotion route or deviate to other groups.  A search capability will allow searching and reporting for a specific message. 

 

There are three roles a user can play: basic user, center leader, or administrator.  Only the center leader can promote the message to another channel.  The Center leader can decide the different routes the message needs to take.  Center leader may want to monitor the message status being worked by other center leaders and coordinate handoff.

 

In many cases, having a centralized point for the mixture of messages makes sense.  So the different groups talk about one topic and work through the issues together.  We anticipate the groups will generate a lot of cross talk and the cross talk will always map back to the originating message.  The cross talk remains as support communication.  Cross talk may include two types of communication coordination: general discussions and more department-specific communications.  The user can segment the type of cross talk communication by adding a user define feedback topic to post feedback too.  Perhaps a gag topic will be created to talk trivia and post personalized social information not relevant to a work topic.

 

The work message will receive the following

 

 

Authentication

 

There will be three levels of authentication:

 

Each resource can be assigned the following privileges

 

All Privileges

Post a Message

Promote Message

Add Note

Cross Talk

Change Priority

Upload Document

Download Document

Delete Document

Resource Admin

Message Admin

Form Admin

Authentication

Channel Admin

Remove Note

 

Basic Entry level User

Post a Message

Cross Talk

Add Note

Download Document

 

Super User

Post a Message

Add Note

Cross Talk

Upload Document

Download Document

Delete Document

Form Admin

Remove Note

 

Administrator

Post a Message

Promote Message

Add Note

Cross Talk

Change Priority

Upload Document

Download Document

Delete Document

Resource Admin

Message Admin

Form Admin

Authentication

Channel Admin

Remove Note

 

    The user will prompted the first time to take ownership of the system.

Center Leader Promotion:

 

The user applies for leadership promotion by entering in the authentication code. Only the system administrator can change the authentication code to avoid abuse by unauthorized promotions. A member list will show the leaders and the basic entry users, so the community will spot intruders immediately.

 

Member List

 

A way will be developed to allow everyone to identify who's online.  Center leaders will be able to run reports to see if the right people involved in the decision process and are notified about requested assistence on a specific message. 

 

Channels with a key symbol, will restrict entry, by assigned personnel. A Center Leader or Administrator will be allowed to assign personnel to a channel. A channel can be viewed by anyone if no personnel are assigned to it. However, once a channel has been assigned to specific personnel, only those personnel can view the message. Anyone can post the message. 

 

Command central will have a series to “light signals” that tell if the group

 

  1. Online
  2. Working a specific message
  3. Not available

 

Cross Talk

 

Side conversations will be possible through cross talk communication.  The “Cross Talk” feature will group members to talk offline about the work message.   This will keep the main message structure from getting cluttered with trivia.  Cross talk will allow group members to continue a side conversation about the message.  Members can post messages to external individuals.  The system will generate an email notification to the external individual letting them post a response back into cross talk.   Only members are post Cross Talk messages, but any external individual may respond.   So one will be able to see the posted messages and the external responses.  This feature provides the ultimate security and traceability for logging email correspondence.

 

The system will be pre structured when a certain message arrives on a certain channel number that all members in the group will be notified by email that a new work message is pending.  An individual can belong to one or more channel groups and it is possible for them to be working many messages simulateously.

 

Each individual can filter messages arriving in channels for which they have responsibility over.  This will allow the individual to know immediately when a message has arrived requiring their attention.  It may become necessary to segment individuals into roles and limit their privileges on the message, such as, priority assignment, message promotion, and comments/document attachment.

 

The SRS email component will allow feedback notification requests to be sent

from the orignator to a specific individual or group.  This functionality will be a part of the cross talk.  The cross talk feedback item will be posted in the database and an email sent out telling the group, a cross talk item is awaiting their response.   The email will contain a link back into the feedback message. So SRS will use email to notify and coordinate activity occuring within the SRS.

 

Promotion

 

Center leaders have the privilege to promote a message to another channel.  This is done from the message page by selected the target channel and pressing the promote button.  A history note is append to the message with the following information:

 

 

So as, the message gets promoted through the pipeline, messages with higher priorities get the highest visibility.  Also, the user can filter messages according to a specific message priority.  At a glance, you should be able to tell how someone is doing, like on a scale of 1-5, if they're up and running or just barely communicating. 

 

Follow-up will be critical.  People can select how much message traffic they want to see based on the priority system.  They can ask for all traffic, only priority 1s, etc.  If a hospital is burning down, you don't want it to get lost in a thousand incoming messages.  Filtering and deciphering information quickly will be important.  If their state is '0', we know they're not okay.  Once the workload starts, keeping track of the progress becomes critical.  Estimates to completion should be available to show progress.  The survival center might have a person delegated to review only (priority 1) traffic.  Another would only get priority 2 traffic.  Lower priority messages can be moved to a low priority queue and worked when convenient.  The idea of segmentation and integration is definitely required. 

 

 

The Emergency Plan

 

Sometimes the center leader will become overwhelmed.  Other times they will need to get more information.  The cross talk forum allows them to talk directly with relevant resources to get more detail.  A system of color codes will help them understand their message status.

 

Each community will have a different emergency plan.  It is important to careful review the emergency plan and make sure that a continuity folder is created to document a series of checklist items to follow.  

 

So the checklists represent the sequential steps in the emergency plan.   Center leaders will be able to set up an checklist template and once the template has been defined with questions it can be used to store the center leaders responses.  The structure of the checklist is a set of questions with checkboxes for leader to click.  The information is stored in the database.

 

Some indicators would tell progress, others would tell workload, etc.  Each community would have its own workflow plan.  Other indicator lights would designate specific needs.  The workflow plan would need to be pre-set-up.  Messages that don't fit the pre-design workflow could go into an overflow area where a specialist could decide where to route it.  I think if the message goes to the community and it does not fit a classification then they have a miscellaneous channel, and then they research where to put it. 

 

Reporting

 

Reporting will be important.  We want the submitting source to do a lot of the classification.  Reports need to be generated by the system like a to-do list.  A generalized report could be based on the color of the indicator lights on the state board.  The message system must be comprehensive, versatile and easy to use.  People will be under extreme pressure.  There will be a lot of garbage coming in.  They will need to sort out what is accurate and what is false.  We may think of all the ways they would use it, but in emergencies, they'll be using it in even different ways we never thought of.  Messages will need to be verified.  Some kind of system of "margin of error" should come with each message.  Is the message source credible or non-credible?  Emergency verification may be required.  Send a resource to see if the building is burning.

 

The SRC will need to be able to produce a number of helpful reports.  A dynamic report generator may become helpful, allowing command center the ability to build reports on the fly, easily and intuitively.