The working day always starts with starting one's own computers or simply opening the notebooks, logging in and reacting to the current events that come in via mails or MS teams. An exception can be the start with a jour fixe. Then this step occurs after the jour fixe.
My place of residence and work is Munich. For all kgs employees who do not live near the headquarters in Neu-Isenburg, the workplace is their own place of residence. So I work from home in Munich.
From experience, my colleagues from my clients' development departments start their working day at around 9 am, so it usually starts at 9 am. However, I have clients who continue to be supported by me after the project and like to start earlier, including an employee of a large client here in Munich. Jour fixe once a week for half an hour usually starts at 8 am here.
It is not easy to explain but nevertheless demonstrable that problems with IT systems often occur after a weekend or towards the weekend. It happens often enough that mails are received early in the morning that indicate problems with customers. You have to know this so that you don't get rattled in the morning or your planning for the day can go straight into the bin.
The working day always starts with starting one's own computers or simply opening the notebooks, logging on and reacting to the current events that come in via mails or MS teams. An exception is when a jour fixe is started. Then this step occurs after the jour fixe.
My personal system of order is to leave the messages coming in via mails that need to be processed in the inbox. All processed messages or those for which I am waiting for a reaction are moved to a subordinate folder, the customer name or other names (private, KGS-internal, PreSales etc.). In this way, the inbox ultimately shows the "workload" or at least the largest part of the "workload".
I already checked the diary for the day the day before. The appointment calendar for the week on Sunday or the day before the first working day of the week. Spontaneous appointments are frequent, both with clients and internally with colleagues. A consultant usually works closely with colleagues from the development department and also with colleagues from sales. My ratio here feels like 4 to 1, i.e. 80% with developers and 20% with sales colleagues. The number of hours is hard to quantify here because the collaboration is very dynamic and follows the rule that collaboration with development is significantly higher for large projects than for smaller projects with standard tasks.
The core competence of kgs is SAP and archiving. For this, kgs has developed various modules which, if they are servlets, are developed in Java. This means that a consultant must have knowledge of SAP and sufficient understanding of computer science without having to program applications himself. However, scripts and smaller ABAP programs are definitely required. Thus, an essential part of my job is to have the kgs tia® modules I use installed on my notebooks, to update them and to be able to use them at any time. An SAP system should also be available locally or accessible via the internet either at the head office in Neu-Isenburg or in the cloud. The kgs tia® modules run locally and at best use cloud systems, such as storage systems from MS-Azure or Amazon-S3.
Regardless of which clients one continues to support after the project, one or more kgs constultants usually carry out projects. This is usually not one project, but several projects running in parallel. Project work always follows certain rules. A project needs someone who has the overview and a plan for it - either in their head or, better still, stored digitally. Projects take place with kgs and a client together. Therefore, the exchange within the project is very important. So there are regular meetings, which can be jour fixe meetings or meetings according to fixed patterns, such as events (milestones). In any case, consultation with the client is necessary. Then there is also the technical area. Projects are implemented both organisationally and technically. Depending on the size of the project, more or less kgs tia® modules/systems are embedded in the client's technical landscape and this always has an impact on their internal processes (i.e. organisational influences). The usually heterogeneous technical landscape of the customer therefore also requires a sufficient technical understanding, because here the kgs consultant also has an advisory influence on decisions of technical components (which operating system is chosen, which (long-term) storage system and how many are used, fail-safety, storage and disk sizes, database design, etc.). Thus, projects can be managed both alone and in a team.
