How we introduce Vertec to our customers
In an implementation project, Vertec is adapted to your needs by your Vertec advisor and integrated into the existing IT infrastructure. Specific evaluations or a connection to an already existing system, e.g. financial accounting, are also possible without any problems.
Training Courses are involved at the start of the main project in order to involve customers in the process and possibly reduce services. Vertec recommends that core team members build Vertec know-how as early as possible in the introduction phase. It is suggested that they attend the course Course Fundamentals and administration “ for people who will provide internal Vertec support and for people at the extension between project execution and finance and HR (target time management).
For people who also want to customize Vertec independently, the course “Setup and customize “. The training mentioned is considered to be basic training. Experience shows that during the implementation phase, the core team builds up a very good knowledge of the system.
The Vertec customer is supported by the responsible project leader during the pre-project and the Vertec implementation project. Accord to the underlying process “Build” (project management), the Vertec project manager is the contact person for the customer (single point of contact). Vertec is a process-oriented organization according to ISO 9001. As part of the go-lives at the customer’s siteapplies the process “Run” (support) process customer the operation of the Vertec installation at the customer’s sitecustomer The support team can be reached through various channels: phone (mainly used channel), email, remote maintenance.
Customer feedback as part of ongoing support can provide inputs for further development of the software. This task is handed over to the “development” process (product management) and the customer is noted so that he or she is informed when it is implemented. The development team in Zurich realizes one to two software releases a year. These are documented in detail with release notes. And the Vertec advisor informs the customer above all about those innovations that will generate additional benefits for him or her.
The Vertec advisor (process “Build”) is then (in the future) the contact person when an extension order comes up. Enhancements can be triggered by a release or by additional/new requirements, e.g. the implementation/connection of a DMS (“Change”). All participants (stakeholders) always have access to the Vertec Knowledge Base . Vertec has a dedicated section for documentation in the Knowledge Base (process documentation).
When it comes to data migrations, a large part of the success lies in understanding the customer’s existing data (data analysis) and creating the best possible logical mapping to the Vertec object structures. Vertec has extensive experience in data migration from legacy systems. We differentiate between master data and root data during migration.
The root data are static data such as employees, addresses, projects/cases and others such as rates. Transaction data are, for example, open services, open expenses, downpayments (account invoices) or invoices on projects/cases. In many cases, the customer decides to migrate the root data, in rare cases also to migrate the transaction data. The jointly developed migration concept defines the scope, type and specific procedure. The data analysis of the root data is always at the beginning, followed by migration iterations until the migration is “right” and you are ready for the productive migration. The latter is done after the effective date from which data will no longer be maintained in the old system. This date is ideally chosen as close as possible to the time of go live.
If an (automatic) migration of transactional data is also envisaged, this data analysis starts after that for the root data. What follows are also migration iterations. The productive migration of transactional data is usually done after Vertec’s go live. Consider the risk of a data migration, migration of master data is root data significantly less risky than migration of transactional data. This is also a reason why many customers do not migrate transactional data in practice.
