Our company, here in Chisinau, consists of 4 departments: Development department, Service department, Realisation department and of course the Administration. Each of these departments have their specific work to do, and in this article, I’ll mainly talk about the Service department, part of which I am.
Short History
At the beginning, in our company in Chisinau, there was only the Development department. Everything was going well, everybody was pleased how do things work. After few years of coworking, it was decided by our HQ in Netherlands to create a Service Department in Chisinau as well. It was quite a risky decision, since Service has to be in touch with the customers all the time.
Department structure
Development department, together with Realisation one, work on implementing the project solutions for our customers, from scratch. Development does all the software part while Realisation takes care about the hardware part. Once done, the project is handed to Service department. So starting with the Go-live phase, Service is responsible for that project, and all the communication, all the requests, complaints(if any), are processed by us. For this purpose, at Service there is a variety of professionals. We have Account managers, PLC engineers, Hardware engineers and of course Software Developers.
For Service department here In Chisinau, only software developers have been hired. The team started with one developer, and in 6 years, it has grown to 10 developers.
Over our department there are several teams which are supposed to do different things, for example PLC team is responsible for the PLC controllers and conveyor system at customer’s warehouses, hardware team is responsible for electrical and mechanical stuff. Account managers are in touch with the clients for keeping the good relation, proposing and negotiating request for changes and so on. But all these teams are only in our HQ office in NL.
However, the software team at service, is the biggest one. It consists of almost 20 people, from which 10 are in Chisinau. Because the team is quite big, it was decided to split it into 2 smaller teams. Each team has a team-leader and a certain set of projects to take care of.
Tools used
At Service we use several tools, that make our lives much easier. One of them is Jira for issue and project tracker. Here we have a KANBAN board for each team, with existing issues for projects the teams own. Issues are reported by one of the developers, added to Jira with the needed information, so that the assignee developer can easily understand what is required from him to do. We have a specific workflow statuses at Service, and they are the following:
- When the issue is picked by a developer to be solved, he changes its status to In Progress;
- He finds a possible solution for it, adds a comment to the issue with his thoughts and update the issue status to Design to be approved, and assign the issue to a senior or medior developer, for example his team leader, so that he can approve the solution or suggest some additional changes;
- When the design is approved (status changes to Design approved), the issue is assigned back to the developer who proposed the design, or it also could be another developer, who will proceed to the implementation;
- Now, the status has to be updated to In Progress, and the implementation starts;
- Once done, the status is again changed, this time to Implementation to be approved, and the issue is assigned again to a senior, so that he can check the implemented solution. Here, some updated notes are added to the issue with the link to the committed changes to SVN, database packages to be recompiled (if any), and maybe some database data manipulations;
- If everything looks good, the implementation is approved, and status is changed to To be Updated;
- Now, having the update note mentioned above, it should be possible for any of the Service software developers to perform the update to the customer. This moment should be coordinated with the client, to arrange a time window, so that it would have minimal impact on the warehouse work time. Every minute is taken into consideration. Once updated, the issue status is changed to Closed, or it could also be Feedback or even To be validated (in case we need a confirmation from the customer if everything is going well).
OTRS
Another tool is OTRS – a ticketing system. Here we receive emails from customers about their complaints, requests and other questions they want us to resolve. Suppose that they see an unusual situation, which shouldn’t had been happened, they write an email, or, if it’s urgent, they can even call. The engineer that answers the call then creates a ticket in OTRS, and assigns it to the right person to check/solve the incident. Incidents have higher priority, and have to be fixed as soon as possible, so that if for instance a developer is working on some issue, he must first check and resolve the incident, and then return to the assigned issue he was working on. Once the incident is resolved, the ticket is registered. And for this purpose we have another tool.
ServiceTool
ServiceTool – is a tool, implemented by our company, where we register calls and incidents. Here we have to chose the right project, contact person, the issue type, we also have to decide if it is an invoiced or un-invoiced incident. We also put down the description of the incident, solution for it, and if needed, some developer info which can be later used for similar issues. Regarding the paid solving, it could be that something wrong happened at the client side due to the incorrect use of the system by an operator, or it also could be a Host issue. Then we register spent hours on this incident, and an invoice is sent to the customer.
Smart tool
As our team is quite big at the moment, we are located in three different places: two separate offices in Netherlands and one in Moldova, there was an idea to have some web cameras in each office, so that we can see each other. But it would have been a bit boring to have only the live streaming on the big monitors in our offices. So, we decided to add some useful information there. Since we are using quite a few tools, we thought that it would be a good idea to have a summary of all of them on that page, together with the live streaming video. The picture below shows what we have at the moment, and it’s still improving.
Here you can see the 2 live streaming cameras, one from one of the offices in Netherland (bottom one) and the one from Chisinau. There is also some statistics about Open/Assigned/Unassigned tickets. The list of unassigned tickets with the subject and the corresponding client. Also there are the issues from one of the KANBAN boards.
An important thing to mention is that every office has it’s own dashboard, so that it can see the other 2 teams.
Experience at Service
At ISD I was hired as a service engineer in 2014. It was a challenge for me, since I’ve never done Java programming before, only SQL and PL/SQL development. At that moment there were four of us, and only two had experience being developers at Service. First of all, every new programmer at ISD, starts with doing tutorials based on real projects, to understand the business logic better and to get used to the system, and step by step he is involved into bugs fixing, incidents and issues solving. Besides that, service guys have to be stress resistant since there are situations when fast reaction is required, and you must have everything under control. I must say that being a member of the Service department I became more responsible and organised.
I like working at Service, our team is very friendly, we can learn from each other, we can rely on each other, in other words it’s a pleasure to be part of Service Department.