Company Wiki

This page is a place for brief documentation and organisation of the things that shape the business, its internal and external processes.
The page is dynamic and will grow and expand together with the business.

Useful Information and Links

IT company
Our IT Department provides IT support for Velador.

Software Tools Used

Amazon WorkSpaces – AWS

At every desk there is a thin client, optimised for establishing a remote connection. You can log in the client using Velador credentials and password, that you will be provided with. In the client environment there is an Amazon WorkSpaces application. To log in it you will require your personal login and password. Even though, it is possible to use thin client’s environment for web-browsing and other tasks, you should be never carrying out any work there. All work should be conducted in the Amazon WorkSpaces application only (or analogous).

Amazon WorkSpaces can also be downloaded on a laptop computer for remote work. After installation you should enter the following code: wsdub+BEGWV5.

For security reasons, when working remotely, you must always lock your laptop with a password and confirm that there is no visual hacking threat.

Microsoft Outlook

An application for emailing and calendar. This can be used as a desktop application, online or/and mobile application.

Microsoft Teams

A hub for team collaboration. There is a chat for every project. Also, there is “General” channel in the “Veladorians” group, for general enquiries.
The application can be used as a desktop application, online or/and mobile application.

Microsoft Planner

The application can be used as a desktop application, online or/and mobile application.

TSheets (link)

e-days holiday planner (link)
Online system representing holidays, sick days etc.

Dropbox

RStudio

IRIS Accountancy Software
An online software showing employee’s monthly payslips.

A guide on conventions to be followed in the company

A standardised way of dealing with processes in the company brings a higher level of organisation and structure. Some of the standardisation benefits are:

 

  • All the team members have an improved understanding of the processes managed by others.
  • Improved clarity in the code. This reduces time of code review (another person’s initial review) or code understanding (coming back to someone’s code in the future).
  • A reduced “key man” risk. It becomes possible and relatively easy to find the required documents, even if the person working on them is absent.
  • Consistency in files names and content, when sent to client. Looks professional and easy to follow up any issues.

Here follows a list of the processes to be standardised and a brief description of each one:

Folders / files structure

As a rule of thumb, folders should be organised “from the general to the specific”. When working with an S: Drive, it is nice to divide all the work into “US”, “Europe” and “Other” folders. Thus, it’s easy to provide/restrict access to relevant employees. Next, there should be separate folders for each of the clients. Next, create a folder for each of the project we do for a particular client. In that folder, the following structure preferred:

  • “tools”. Contains git repository, with all the code files done for that project.
  • “output”. Contains all the produced files, that were (will be) sent to the client. This is a folder with the final versions, containing “veladorised” documents, with disclaimers etc. It should also contain a description file (.md / .doc / .txt), with a brief note on how each of the files was obtained (path of the template used / code output file path etc.).
  • “data”. Contains all the original data obtained from the client in a subfolder “data_1_raw”. Also, contains all modified versions of this data (e.g. “data_2_csv”, “data_3_consolidated”).

All folder names should be in alphanumeric format and should not contain any white spaces characters (use “_” to separate words).

If the file is likely to be used for other client’s projects, it should be moved to the client folder. If the file is likely to be used for other clients, it should be moved to a respective folder (e.g. volume_report_template.doc should be moved out of specific client’s folder. “ecb_rates.csv” should be similarly saved outside all of the projects/clients folders.).

Files names convention (internal)

No white space should be used (“_” used instead). Alphanumeric format.

Files names convention (external – sent to the client)

We can use white space here, as these files are copies of our results. They are final versions, only to be sent out to the client. There is no need to mention the client, but we should mention specifics/projects. Separated by comma, we write the type of the document produced at the end of the file name (no capital letters at this part). E.g.: “Bank 1, interest rate calculations.xlsx” or “John Doe, report.doc”.