Introduction
Background
The company which this experience stems from is a company located in Dartmouth, Nova Scotia; this company is called Glow Parties. Working under the direct supervision of the general manager, my official title was Audio IT Tech. This position meant that I was directly responsible for the majority of the Audio Visual side of Glow, but also the entire IT wing located at Glow as well. Upon stepping into this role, there was clear evidence that areas within Glow IT was severely lacking or non-existent. One of these places was a centralized administration for all of the IT information, support, documentation, and inventorying tools for the IT department. This lack of clear administration and management made the transition into the role difficult. Seeing the need for not only my personal use in the company, but to add a future proof tool to help the department grow or transition to a new leader if needed, I opted to make one of my first goals establishing a tool to work alongside my time at Glow.
Goals of the Solution
Outlining a series of requirements of the product to implement, I began to list what tools and abilities I want my solution to have would keep the project focused and in scope of the needs. Firstly, I wanted a completely free solution, to justify a purchase of a tool kit at the time I felt would be out of place for a new hire and instead I wanted to use a free or open source tool to accomplish my goal. I also wanted it to be self hosted, Glow at this time transitioned to a new Virtual Environment I implemented for them a week before hand. So self hosting was the obvious choice rather than purchase space elsewhere in a cloud. The final requirements for the final product were:
Inventory Tracking - The final solution should allow me to document, store, and actively track all Glows IT assets. And also allow me to “Stow” and “Deploy” relevant assets to “Locations” as needed by the company. This not only tracking what Glow owns, also allowed IT members to located where a specific system is located, along with the purpose and specifications of the system itself.
Maintenance - The product should allow me to place assets into maintenance or at the least track when maintenance should take place. Also allowing for product lifetime tracking to understand when a replacement should be looked at to be purchased.
Repair - A module or tool to track repairs of assets is a must. This module should track when a product needed a repair, why it needed it, and what was done to fix it as needed.
Project Management - A lot of my job was project based and planning long projects for the future, a tool inside to also track active IT projects was also added to this list.
Support Request System - Some tool or adapted tool to track support requests and follow them through a natural pipeline from start to finish was mandatory. Rather than having a all the requests handled via email and lost to time.
Solution
With the list of clear functions I needed my solution to contain, I started researching into either a solution to build from, or a solution which already contained all of the required resources. The first thing I decided was that this needs to be a web based application for two reasons. Firstly, if its web based, I can use any device on the Glow Network to use the tool such as a smartphone or tablet rather than a program located or needed to be located on a computer. Secondly, I wanted the tool to be located on a server preferably Linux for its small footprint rather than on my work machine. Placed on a proper server with server grade gear would be massively more reliable than the decade old laptop I was assigned.
After some research I found a product called Odoo, formerly know as OpenERP. This tool programmed in Python was an ERP, CRM, CRM, ERM, all in one. And on top, your base installation was very much blank and you built it for you and your needs. This tool also had a massive community base and thousands of community apps which could be installed on top of the base installation. It being open source meant that I could use it for free, and the massive and matured community offered a plethora of information to pull from for troubleshooting.
This was the selected program I would use to build the IT management at Glow.
Implementing the Solution
Server Side Implementation
After looking into the various deployments of Odoo, a GitHub post pointed me to a Turnkey installation of Odoo. For context Turnkey Linux is a series of Open Source projects pre packaged into a Debian based installation. I chose this approach since its simplistic and it reduces time on testing and setting up all the aspects of the install. Webmin and all the account passwords were set up successfully.
Building The Tool
With a clean slate the first modules I went for was the following:
Inventory - Create products, items, locations, stages, and various other operation types. This module would be used to track the “deployed” and “Stowed” computers and assets used by Glow. While also maintaining their specifications and other data like their hostnames and purpose at the company.
Repair - This module allows me to schedule and track repair requests on equipment. Track what expenses were applied to the equipment and log notes on how it was repaired, along with who repaired the product.
Maintenance - Schedule maintenance and lifetime of products, once configured I had hoped it would allow the successful tracking of product lifetimes and allow a simplistic approach to phasing out old equipment with new equipment coming in on a regular basis. I was not located at Glow long enough to complete this module.
Project - A module which would track projects or build a pipeline for a process. I used this module to track assigned projects, and also the support ticket system.
Notes - A simple module to store notes on passwords, documentation, invoices, etc.
Operational Results
Inventory
The inventory module started by first accounting and tracking down all the computers in use at Glow. This was the most tedious process since it required locating computers stored under desks and behind cabinets rather than in a central location. Once located, each computer was assessed, evaluated, and then checked over for any immediate repairs or maintenance which might be required. A rough cost estimated based on what the unit was worth was also done.
Once all the products were inputted and installed to the system I had to take an inventory, assets were either “stowed” or “deployed.” Locations in Odoo are broken down into “Warehouses”. The warehouses setup were for the various locations computers could be stowed or deployed. Once the asset was finally added and inventoried I would know where, what, and who was using each asset. An internal reference was added for an individual who used a asset, or any additional information of where it was stored. If there was multiple systems of the same type in storage, they would be combined and a total count would also be displayed.
The very nice thing with Odoo is that all the apps work together. Each asset in inventory was called on and referenced in the maintenance and repair modules as well. So in time with further use, a user of the system can track a full 5 year lifetime of a product from where it's been, who has had it, and any repairs it's needed.
In this example, the asset described is a custom production PC used by one of the graphics developers. It outlines the basic specifications of the device, who is using it, and it's hostname if needed in a networking event. There is only one of these computers, and since this one is ‘deployed’ there is no “one hand” quantity at this time.
Repair
This section allowed IT staff to ingest repair requests, assess a response, and then complete a repair. This module also fell back on assets IDs. A request would come in, a “customer id” would be assigned and then a technician can start the repair. The repair module also came with an invoicing/expenses module as well. This meant if parts or added costs came to a repair, an in house invoice can be made and assigned to the record if needed.
This module was relatively straight forward and easy to install and prepare. Orders are made from a central location, a UID is assigned and then product selected.
Project
The project section is where I was able to combine parts of the IT sections into relevant pipelines or projects which needed to get completed. There is four main sections Documentation, Invoices, Passwords, and Support Requests.
Starting with Documentation there is three main sections, Incomplete, In Use IT Documentation, and other Documentation. I was not at Glow long enough to continue preparing operational IT documentation unfortunately, however I was able to prepare a few smaller examples and gather up the limited documentation on certain aspects of the company. The below screenshot is the pipeline and what it looks like for Documentation. The second screenshot is an example of what documentation can look like for IT staff to pull from.
The second part of the project module was the invoices area, this generally was just an area to store all the invoices generated by the repairing and maintenance departments. It was generally not in use mainly just a place to store tracked expenses. None of my repairs at Glow warranted an invoice so I don’t have an in use screenshot to demonstrate its use.
Using The Service in a Production Environment
Support Requests and Ingests
At Glow with a central office staff of about 10 people the current situation the adaption or changes would cause more issues so the current solution and the one I kept was an automatic form generated on Office 365 which basically asked for the employees info, what would happen, if they can replicate the steps for the issue, and when the issue started happening.
Once the form was completed an automatic response form was sent to the main Helpdesk email with all the responses organized properly. Some times employees would just email this mailbox with their problem. This genially meant I had to respond in a manner to determine the remainders of the information of the request in question.
Once information was attained I would spend the time to convert it down into Odoo in the project form, documenting the relevant information along with the initial email and the following important one. The main reason why I did this was in case the problem occurred again, there is a record of all original information and communication for reference.
Once information was determined, I would evaluate the scale and priority of the request, generally what was operationally affecting the client and what was more of an inconvenience but was able to continue work. An example I got once was in one day, one member of staff the accountant was unable to communicate with the accounting database and another one was unable to directly import documents to the Mail app, and had to save the file first instead. In this case, the accountant got a priority One and a Star for operational issues since they are unable to complete the work they are being paid to do, while the other request got a priority three since it was more of an inconvenience rather than an actual issue in the production environment.
Support Requests and Ingests
When the requests were ingested it was based by priority where the next requests would be processed by a technician and there progress was tracked and recorded within the request itself, if a repair request was also needed it was referenced here in logged notes as well.
Requests would move through stages and be slotted accordingly, there was requested support, where reports were started, priority assigned and waited until the request was started. Started request would move to the next stage which would be in progress. This is where a technician has decided to take on the request and begun the process of handling the request.
Major events are logged here and any major changes as well. The final fix as well is also documented even the simplest fix such as turning the device on and off simply in case the problem arises again there is information to reference.
After a repair is completed and the request is finished it moves to the completed requests for a period of two months for any quick references or if the request is opened again for whatever reason. With all my requests generally speaking none of them had to be reopened in my time. Using two months at least gave a fall back and once completed they would be archived to keep the space neat and organized. The joy with Archiving is that I would be able to keep the records behind the scenes to also pull up on specific clients if the problem occurred again. In theory the archived case would continue to remain as long as it wasn’t deleted so any technician can reference the material if needed in the future.
In the event the case was cancelled or dropped then the case would move to another category called dropped requests where they would archive after two months. This location is really just kept in case once again the case was reopened to complete a fix.
After the request was completed and the client confirmed the fix, they would move the completed category where their two month waiting period was started.
Overall this system centralized the complete IT department at Glow, ranging from requisition orders, password management, and Customer Support/Help Desk. On the Help Desk portion, the official production SOP started at ingest: employees were asked to complete a required 365 form, where relevant questions were asked about the issue, the environment, can it be replicated, and the effect it had on the worker. From there the request was referenced with any previous requests which may have entered the system before. If not the request was made into its own template and all the relevant information and who we are supporting get documented.
Once documented the request was determined how important it was, from low priority where the problem is inconvenient to a user but didn’t really affect work. Level two where certain parts of the workers job was impeded slowing their work down. Level three where a major aspect of their job was unable to be completed in turn meant a worker was unable to do the majority of their work day, and finally a level three and a gold star meant that a worker was completely unable to complete their work, the problem was company wide, or requested by high management.
Once I got all the information down and the request was started all communication via email or notes in person were logged as the process continued. This was done so any people who wanted to reference the request in the future was able to. Odoo has a feature where you can attach an email server itself to the Odoo instance and directly communicate with Odoo and a client, but Glow did not run its own Email server and was not interested in setting one up so this feature was cancelled. If it was present I would be able to combine the methods of communication and automate logging but the request was denied. Clients profiles were made as well, this way employees had a record of past requests to see if there was any trends or recurring issues to further investigate or follow up on.
Documentation as needed was also stored on the main Odoo instance again to centralize a lot of the information and administrative work. If a request came in for an employee to change their phone password, a technician was able reference that resource in the same location streamlining the entire process.
As for decision making and troubleshooting. The general approach I took was first identifying the exact problem. With some research into Helpdesk a lot of resources started here. Asking the right questions to really identify the who, what, and when become insanely important in determining the why. Then generally I would reconfirm my understanding of the issue itself just so both parties are on the same page. If applicable or needed, I would also just go in person to witness the issue itself and go from there. Witnessing the issue was a double edged sword since it was more spur of the moment and I could be busy elsewhere but it was the easiest way of determining key variables in the problem. Then I began to eliminate any variables in the entire problem. Can the event happen in another environment or on a different computer. Is there an error message displayed which can locate the exact problem itself occurring. Did the clients computer or the relevant asset log the event. A lot of research suggested a proper monitoring tool such as Solarwinds or LibreNMS to monitor the networks as needed. This next step came in handy a few time, in one request I got from an accountant that they were unable to connect back to the Simply Accounting server. After checking the logs of the client and the server, I was able to ascertain that the reason why was because the Client had a sudden disconnect from the network while the server didn’t drop the connection. Meaning that the client could no reconnect. Requiring a restart of the service too clear said connection. Next with all my information attained I would begin my work into determining the root cause of the issue. In even my short time present, I noticed that most issues seemed unique but many had a same root cause whether it was a network disruption, or a bottleneck somewhere. Finally the last thing I would do is document a fix rather than a patch job, If possible future proofing the solution was the final and last step in my process. To avoid potentially having further issues on the same root problem if I could place documentation and a full fix to a root cause that would help prevent the problem occurring again in the future.
Conclusion
Overall the solution I put in for Glow centralized the IT department from its record keeping to its Helpdesk management. With the solution I placed it met the current demands of the current help desk environment I believe as the company grows as well, that Helpdesk process can be streamlined and made more automatic as more employees are hired on generating more tickets.
If I still worked at Glow I would probably opt to change parts of the entire service to be more descriptive to people who are not Tech Oriented. What I mean by that is members of high management which have access to reference the website for their own reasons; a better way for them to understand what is happening and why pretty much.
If there is any question or a live demo needed I am welcomed to providing one at this time. A letter from my general manager is also attached agreeing that the service was installed and prepared by myself and only myself.
