"Hey Vera, what does an application consultant actually do?"... A conversation between Vera and Verena

Vera Quensel has been working at the priint Group as an application consultant for the last three and a half years. Out of curiosity, I asked her what her tasks are, what motivates her every day and what tips she would give to her fellow applicants and new colleagues.

Vera, you've been with us for over three years now. Why did you decide on this job back then?

That was very exciting for me at the time because I actually have a completely different background. I originally studied mechanical engineering and also worked as a design engineer for three years. During that time, I realized that the profession I had chosen didn't drive me any further, so I began to look for alternatives. In my studies, I had computer science in one semester, which I enjoyed immensely. I then built on the basics I learned back then and educated myself a bit more. Then I started at priint | WERK II with not too much knowledge, but with a lot of enthusiasm and excitement.

Does that mean that a degree in computer science is not a prerequisite for new employees?

No, I think it depends more on the person. A new colleague should be able and willing to work independently on the one hand, but also be part of a team on the other. Because especially when there are problems or new use cases in customer projects, these should be discussed in the team environment. Maybe a colleague can help and already has a smart solution. Since we work internationally and are also very distributed within Germany, close coordination with colleagues is simply important. From a professional point of view, however, a good, logical and analytical understanding, especially with regard to processes and workflows, is important - as is a good technical understanding. However, previous knowledge of programming is of course not a bad thing.

Customer projects. That's a good keyword. What are your main tasks?

It's often varied and that's what makes it so exciting. The core tasks are multi-faceted and include project work, consulting activities, technical project management, troubleshooting and much more. It's really very, very multifaceted, but that's also what makes the job so exciting. To this day, not a single day goes by that I don't learn something new. And that's incredibly fun.

Can you explain the individual areas in a little more detail? What is involved in the project work?

Well, the fact is that either our partners manage customer projects or we do ourselves. Therefore, we either support our partners in the project work or in the implementation, or we support our customers directly. What tasks are involved in the respective project is very different. For example, we do the following activities: implement project-specific placeholders, write project-specific layout scripts or design rules, creating templates according to customer specifications, automate templates and much more.

We currently have 6 application consultants on our team. I imagine that customer requirements may sometimes be repeated or a requirement already existed and was previously solved by another colleague. How do you exchange information within the team?

That is a very important question. Because we also work in a very distributed and often remote manner, communication is very, very important for us. It's important that we inform everyone in the team, for example, about solutions that we have developed ourselves, and that we also communicate our requirements the other way around. To promote this internal exchange, we have a departmental meeting every Friday. In addition, an internal forum was set up last year where we record best practice solutions, and also discuss problems or bugs. Everyone has their own focus and can contribute in different ways.

What are the focal points, for example?

There are no real boundaries there. But some of us, for example, also do connector adaptations (i.e. the interface definition and creation for the PIM or for the data systems). These colleagues deal with the data model.

And many of us can also implement a Java approach. This concerns, for example, the workflow methods or DataProviders. Other functionalities that are stored in priint:planner or in the priint:suite are also written in Java.

In reference to Java, what languages (besides English) should you know?

Yes, English is indeed important because of the communication with our non-German-speaking colleagues. In terms of computer languages, Java, as I said, is more for the workflow topics or DataProviders, which, for example, compile and assemble tables themselves from product data. If someone knows C script or C, then that's great: we use it to program design rules, layout scripts, placeholder actions- basically everything that deals with editing within the InDesign or Illustrator document. With our release of 4.3 there is the extension that we will also support Python as a scripting language in the future, a first beta version of it has even shipped with 4.2 already. Python already has many functionalities from the ground up that would still have to be written by hand in a C script. Therefore we also support Python starting with priint:suite 4.3.

How does the project work across the sometimes large distances?

Our task is to describe our requirements sensibly and comprehensively. This includes various components. For example, "What does the interface look like? What does our entity model look like? What product structure do we have there in the first place? Which templates are needed to map this? Which automation logics do we need related to the page? How does the product have to be placed on the page at the end? How does it have to look? Can it wrap to another page? How do the frames change in relation to each other? There are always a lot of questions, so it is really important to describe everything as accurately as possible. In relation to an entire catalog, for example, the following questions also need to be answered: Which pages are there functionally at all? Is there a table of contents? Are there decorative pages? Are there different product levels that are perhaps displayed differently, (i.e. different hierarchies that have to be mapped differently)? Such things have to be described and ultimately documented. So from that point of view, a bit of paperwork is also involved.

And you clarified all these detailed requirements with our partners or with the customer beforehand?

Yes, exactly. That's also part of it, the consulting work. Here's an example: A customer opens a ticket with us. The problem or task is explained and a solution is sought. Now we look to see whether there is already a standard functionality here or whether we can implement it using a script, (i.e. with a project-specific implementation). In ongoing projects, we discuss the project during regular status meetings with the partner / customer and define the next steps.

But there are an infinite number of different requirements. You can't know all of that all the time. Can you?

Yes, that's true, and it's a challenge, especially at the beginning. But that's exactly what makes it so exciting. And the support of colleagues is always a great help. It may take a little time to get to grips with everything. But everyone gets that time.

What about InDesign skills?

You have to know the basic functionalities of Adobe InDesign and Illustrator. But you can learn that quickly and there are great tutorials on it, plus we also have our own training courses that we can take part in. In InDesign, for example, we create the graphic templates or the sample documents on which you then distribute the placeholders, the design rules, and this whole definition of how such a template is built up automatically afterwards. Much of this goes beyond the standard functions that our priint:comet plug-ins already provides. For example, we have developed a few standard functionalities. One is very helpful and known as "Fit Frame". This is where frames are automatically adjusted. If a frame is too small, for example, it's automatically enlarged so that all the textual content fits inside. And so we have quite a few features that are already there by default. Nevertheless, they are not always sufficient to map all project requirements.

In terms of design, think of it like this: How something looks on the page, how it should be placed, is of course often specified and predetermined by the customer. However, we often have to see for ourselves how this can be implemented. Can you do this with a design rule or do you need another rule that intervenes during the layout? Then you have a so-called layout help script. So there are many roads that lead to Rome. If a new rule is needed, then I program it and it can be integrated into the template.

In general, there is nothing in our system where you can't learn the ropes. Nobody demands that someone has to be able to do everything on the first day. These are all tasks that you learn as you go along.

And what happens when a partner or customer gets stuck in a project? So the keyword is troubleshooting or searching for clues?

If something does not work, a support ticket is opened. Then we usually get log files. We analyze them and go troubleshooting to find out if it's a problem in the project implementation, a completely new feature request or a product bug. So troubleshooting is also a big part.

That's a lot of tasks. What do you think would be most important for a new employee?

It's important that you first get to grips with the subject and understand the connections between what you see in InDesign and what is somewhere in the database. That is, the content and how to get the content into the InDesign document via a script. In short: How do you get the data from the system into the document?

You've already mentioned the cooperation with colleagues. I would like to go into more detail here.

Gladly. For example, if we notice that something is not yet working in a project, we sit down directly with our developers. When it comes to the priint:suite, it's our team in Poland. And if it concerns the priint:comet plug-ins, our developer team in Germany, i.e. Paul's team, is our first point of contact. Together we then consider whether this requirement is something that we can include and integrate in our standards or whether it can be solved via a project-specific implementation, and if so, how. So internally, we have a lot of communication.

If I were to apply to the priint Group as an Application Consultant - what would you like me to know?

To this day, I'm thrilled that this job is incredibly flexible. You don't have the same work every day, there is always something different. Also, it's especially helpful to have the close exchange with colleagues who have experience from other projects. For the 3.5 years I've been working at priint Group / WERK II, not a day goes by that I don't learn something new. In other words, the learning process never really stops.

The second very, very important point is the cooperation with my colleagues. We have an incredibly great team- the entire company and Horst as our boss. At priint Group / WERK II, the focus is always on the individual; you are not an interchangeable link in the chain. And that is what counts. That really made me very happy when I changed jobs. And that continues to this day.

Wow, what a great statement! I'd like to leave that as a closing statement. It's the same in our marketing department. I think this is also a great "spirit" that is in the air or in the company. Thank you so much, Vera, for taking the time. And I feel the same way - I learn something new every day!