Archive for the ‘knowledgebase’ Category

There are so many ways for government to waste money, but learning a little from social media websites, like Facebook, governmental offices could learn to solve problems through crowd sourcing existing staff from around the nation. The government has a wide range of technologies that it uses from Mainframes to SQL servers to Helpdesk software. Even though government agencies are very diverse, most have core sections (Finance and Accounting, Human Resources, Legal Department, Information Technology, and Specialized Staff found within the different divisions of government) that have similar technology support needs.

Technology Support Needs:

  1. Server Teams:

    1. Email

    2. File Storage

    3. Active Directory

  2. Database Engineers:

    1. SQL

    2. Oracle

    3. DB2

  3. Programmers:

    1. Java

    2. VB

    3. HTML

    4. SQL

  4. Network:

  5. Client Helpdesk Support:

    1. PC support

    2. Phone Helpdesk


With tightening budgets and layoffs, CIO’s are fighting a delicate balance of low staffing and still keeping a high level of customer service to the end users of the technologies they support. One way that could help with this dilemma is to have a social media website for government technology staff to bounce ideas off each other. If you look at websites like Facebook and Twitter, you will see that in today’s world, most questions can be answered by asking your friends online. With government there are issues that arise when looking for answers online. The first is that government has many policies when it comes to privacy. You cannot just ask, “What is the best way to encrypt Health information” to the general public.

Another issue is environment. The public sector has a lot more flexibility when it comes to install applications within a production environment. Purchasing requirements is another issue with government. There are times, which even thought the software you have been recommended will do the exact job you need, you cannot purchase it because of money or the company is not on the government approved vendor list.

Even with all the restriction put on the public sector there is still the opportunity to use the functionality of social media sites to enhance technology support within the government. I purpose that the government build a password protected, Facebook like, site where government employees can discuss issues with others government employees. A good example of where this could really work is within the core technology support areas.

A Government Technology site could not only help solve problems with common issues quicker, it could also save tons of money in time and resources. Let take for example email. This is the life blood of most communications within the public sector. By having 60 or 70 dedicated government email specialist from around the nation all in one group you could solve common issues much faster than calling a vendor for support (although I am not saying get rid of the vendor). Not only could you solve issues faster, but you can also help prevent them by discussing best practices with people that understand the constraints of government.

This only one way to integrate Web 2.0 in to government, there are many other applications that can be used to help organize and solve issues.

Advertisements

Below is a list of rules that I found for proper knowledge base entry. A Knowledge base must be made up information that is easily searchable and useful. Below is a list of procedures that all technicians should follow when submitting articles entries to the knowledge base. The steps below will provide consistence and easy of use 

  1. Write a Solution using step-by-step instructions. Paragraph formatting is unacceptable for sequential procedures, but is acceptable for explanations. Steps must be numbered with periods after the steps and two spaces before description.
  2. Start all solutions with a verb. (i.e., Click OK or Reboot your computer)
  3. Use “when/then” statements for steps that include conditions. (e.g. When this happens, then do this) the word if can imply that whatever happened isn’t normal and may cause a lack of confidence if the customer is accessing the knowledgebase self-help.
  4. In all solutions with an indicator marking the end of the solution. For instance sequential numbering “END” as a part of the solution indicates the last step of the solution. Example:
    1. Click OK
    2. “END”
  5. Capitalize letters to emphasize important warnings. (e.g. DO NOT TURN COMPUTER OFF.)
  6. Capitalize the word “note” and follow it with a colon. When making a side comment or drawing the professional’s attention to something important, a side note is appropriate. (NOTE: check caps lock key)
  7. Use dashes to list examples. Follow dashes with a space.

Several things can cause this:

          network cord is unplugged

          dive mapping has been lost

  1. Avoid using uncommon abbreviated words. (e.g. printing should not be abbreviated as PRTG.)
  2. Use a period at the end of every sentence.
  3. Place a space before and after any keyboard character. (e.g., Printing / Printer not Printing/Printer.)
  4. Write solutions in a commanding tone. A solution is a procedure and must be written in a language that leaves no ambiguity. Avoid using words like “please” and “should” on the solution. Effective solutions dictate specific steps that are not optional.
  5. Write out problem descriptions as statements, not questions. Questions or additional information can be provided in the problem cause section of the solution.
  6. Avoid using “you” or “your”. This is unnecessary text for example: “you then click OK” can be just as easily written as “Click OK”.
  7. Use consistent verbs when identifying actions. Use the verb “press” when refereeing to the keyboard keys. Use the verb “click” when referring to the mouse functions. Use the verb “select” when referring to the menu options.

Guidelines for knowledgebase entries:

  1. One entry per problem and cause. For each cause of a problem there should only be one knowledgebase entry.  For example, there should not be multiple knowledgebase entries resolving the same problem.  If there are multiple causes to a problem, there should be separate knowledgebase entries for each cause outlining the solution.
  2. The Title should accurately summarize the article. This will usually be identical or very similar to the “Topic or Question.”
  3. The “Topic or Question” field should be a specific problem. For example, “Having problems in Word” does not outline a specific problem to resolve.  “Word crashes when attempting to print.” would be appropriate.
  4. The “Content or Answer” field should list the cause of the problem followed by a logical solution.  The first line should “Problem Cause:” followed by the cause below.  After the problem cause there should an empty line followed by “Solution:” with the solution listed below.

Here are some quick tips when dealing with a customer service representative (aka Helpdesk).

First, have all relevant information with you at the time you call. One of the most common mistakes when contacting a Helpdesk is not have all your documentation, receipts, or product with you when you call for assistance. You need to realize that the first person you talk to is not likely the most knowledgeable expert on whatever subjects you is having a problem. Helpdesk are normally the first line of defense for call resolution. For a customer service representative to help you they will need all information on the issues. It is best when you call a help line to have every thing in one place so any reasonable question they ask you will be able to answer. The most common question from them may put you at a lost for words without all your documentation. Be prepared to answer things like, date of purchase, model number, serial number, location of purchase, specific issues you having, etc….

Next, give yourself plenty of time for the call. I know most people are in a rush all the time, but that will not help you when you are trying to solve an issue. When you call a helpdesk you should be ready for delays. Be prepared for anything from wait time before a technician get to your phone call to the technician find possible resolutions within his company’s knowledgebase. Usually if you are calling it is because you could not figure out the question yourself. This would indicate that it may take a little bit to find a solution. A good rule of thumb is give at least 30 minutes to an hour, from the time you first talk to a real live person, for you to explain and get some type of resolution.

Lastly, patients, patients, patients!!!! Rome was not built in a day (I know it is a stupid expression), but you can not expect someone to read your mind and fix your problem as soon as you call. I am not saying that you should not expect them to fix your issues. Just that you should understand that helpdesk representatives are not your enemies, they want to solve your problems as much as you want them to be solved. Because in doing so they are helping keep their own jobs secure. A common thing customers calling a helpdesk should be aware is that you probably don’t speak the same language. I do not mean you speak English and they speak Aramaic (well for the most part I don’t mean that). I mean that most likely you speak in laymen terms and they speak technical gibberish. This is really where patients comes in to play. You need be able to articulate your problem the best you can and try to make them understand what issues you are experiencing. They should also be trying to do the same.

Here is a quick tip I have found that helps me let the helpdesk know exactly what my issue is.

Photos: I recently had an issue with a new dryer that I bought. I need to know how to install the power cord in to the back of the dryer. The particular cord that I had did not have a color coded system like the one I saw at the store. Before I call the helpline I took photos of the back my dryer and of the cord and posted them to my website. I then instructed the helpdesk technician to look at those pictures in reference to my issue. This worked like a charm.

I am currently in the process of creating a knowledgebase for my companies Technology department. I am having a difficult time between my vision of the overall process and the vision of my upper management. I feel that we should be planning the knowledgebase for the entire technology department. I believe they seem to think that we should be doing it for just our small subset of the department. The application I administer is used by the entire department for Incident Management (tier 2 support), Change Management, Service Management (tier 1 support), and Configuration Management (inventory). There is a build in knowledgebase module with in the software. The knowledgebase module is directly linked and encompasses each of the modules list before. I want to convey my vision to my management without getting either side frustrated.

Below are a few issues I have and some explanation to why I think my way is the best. I am very open to criticism if you have valid counter points and encourage open conversation why I might or might not be correct.

First, I think that even if we decide to have the knowledgebase only for our subset of the division, it will eventually be discovered by others in our department. I want to start planning for the department as whole instead of being a year into the project and then having to change the way we do things because our user base has quadrupled.

Second, I want to have everything entered in to the knowledgebase. Even the most trivial of task like setting up a network printer. Currently the application works on a submittal process, tier 1 and tier 2 technicians both have the option on close of a ticket to submit the resolution of that ticket to the Knowledgebase approval queue. Once submitted and knowledgebase administrators would determine if the if the solution is a valid knowledgebase article. I feel that to have a good knowledgebase you should have everything recorded at least once in an article. This would then help new technicians with questions they may have about certain technical procedures or help tier 1 support resolve issues that may not have been able to in the past. I do understand that the drawback to submitting everything as apposed to just issues that are more technical in nature is that it creates more work on staff. I feel that the
RIO (return on investment) would out weigh the initial work that you have to put in to have a proper knowledgebase.

Lastly, I think that to truly have a good knowledgebase you will need to have the buy-in of your upper management and clearly written policies that define the scope of what your knowledgebase should accomplish. I feel that in my department as a whole, the upper management is split on how they envision the future of the department. I guess this is the drawback to having a mid-sized computer department that is in charge of supporting a huge user base.