Tag Archive for: ERP Project

ERP project management – a guide

ERP project management tasks: a roadmap for new managers

Experience shows that an experienced employee takes over the management of an Enterprise Resource Planning (ERP) project. This has a number of advantages. They have good technical knowledge and are very familiar with the internal processes of the department – and with the tasks of a project manager. They can also assess their colleagues and make valuable recommendations about the composition of the project team. But as is often the case, where there is light, there is shadow. When it comes to project management, leadership is clearly at the forefront. In many companies, it has become an everyday occurrence: an employee is suddenly expected to lead a team and take responsibility for a complex ERP project – even though he or she is not normally exposed to project management tasks. What is not considered: The demands placed on a project manager are not the same as those placed on, say, a technical employee.

This is naturally a difficult situation where role conflicts are inevitable. The problem arises when the individual’s skills do not match the role profile of a typical manager – or when there is simply a lack of professional experience. Of course, there is nothing wrong with taking on new challenges. However, this confrontation often results in excessive demands, which can easily lead to poor decisions and conflicts. Especially in an ERP project, where a lot of time and other resources are invested, this is of course counterproductive. This article summarizes some useful tips to help you get started as a newcomer to project management.

Before the project starts – a structured approach to new tasks

But before you change your mind – with good preparation and a good team, you can look forward to your tasks as a project manager with confidence. The first important things you can do before the project starts. There are basically three areas that will influence your success as a project manager without a direct line manager function.

  • The factual, organizational management level
  • The human, personal level of your colleagues
  • Your own understanding of your role

The management level

The implementation of an ERP project is always a temporary double burden for the individual team members. Everyone should be aware of this if they want to be involved in the project implementation. Nevertheless, the temporary extra work is often the source of conflict. The reason is easy to find.

An example

Let’s say you didn’t sit down with your key user’s manager to discuss the project before it started – simply because you didn’t know it was important. The project begins, and you as the project manager and the manager continue to demand the employee’s attention. You delegate tasks to them, they continue to report to their regular manager, and they still have to manage the normal day-to-day business. Your key user is finding it increasingly difficult to juggle the project and day-to-day responsibilities. He now has two options: Either he communicates in time that he is overwhelmed and needs help, or he allows the situation to continue as before. Either one side falls by the wayside completely, or both sides are dealt with half-heartedly. In the end, it is the key users who have to deal with the backlash from the department and their project partners – as well as a lot of overtime. The result is usually overworked, frustrated project members who are not likely to be available in the future.

Involve your key users’ managers

Fortunately, this is a situation you can easily avoid. As is often the case, the key to success is communication. If a key user is not being adequately supported, it is your responsibility to sit down with the appropriate manager. It is best to talk to the manager before the project begins and work together to find a solution. This is an important step to take, because you as the project manager have different goals than the department head. In this way, you can clarify different interests, policies, and controversial points without putting them on the backs of your employees. To successfully complete the project and keep the business running, everyone needs to be on the same page-even if that means taking on a task for a colleague or working an extra hour. Make it clear to everyone that this is a temporary change that will ultimately benefit the entire company.

“ERP project management takes care of itself”

The same is true for you as a project manager. This may sound like an exaggeration, but managing a project is a full-time job. An ERP project requires constant attention and coordination: you are in constant contact and exchange with management, key users, department heads and the customer.

frischgebackene-projektleiter

The colleague level

Get to Know Your Project Team Early

In order to perform your duties as a project manager well and conscientiously, you should get to know the members of your team. If you have the opportunity, try to participate in the composition of the team. It is part of leadership to observe the strengths and weaknesses of individual employees and offer them room for development. Only when you know your team well can you assign tasks and coordinate the team. Questions to ask yourself

  • What are my key users’ strengths and weaknesses?
  • What are the relationships between key users and their peers?
  • What are their special skills?

A kick-off meeting is especially useful if you are working with colleagues with whom you might not otherwise have much contact. It allows you to sit down and get to know each other before the project starts.

Understanding your role

The role conflict mentioned above is probably the most difficult challenge you will face as a project manager. There are countless ways to lead a team. What are they and how do you find the right one? Basically, someone in your position already exudes a certain basic authority and competence. You can either explain everything in detail and justify every decision – or you can simply present your team with a fait accompli. You can approach your colleagues on an equal footing, act as a coach, or simply issue blunt instructions. One thing to keep in mind: In everyday life, you work together as equals, possibly performing the same or similar tasks. In your role as project manager, you automatically move up a level on the hierarchical ladder, even if only temporarily. You become a kind of superior. If you take advantage of this situation and simply give orders, you will not win any points with your colleagues – and your acceptance will certainly be diminished.

Project success vs. colleague relationships

Of course, every project manager wants to see teamwork between employees in order to complete the project quickly. However, you cannot and should not rely on this. When in doubt, you need to be able to take action to get the project and people back on track. Ultimately, you are responsible for the outcome and success of the project. Success is measured by whether you achieved the project goals on time and on budget. How people feel about you or your methods is ultimately irrelevant. However, there is life after the project – and you will no doubt want to maintain a good relationship with your colleagues. What is the best way to handle the situation?

Finding a good balance

You are probably in an unfamiliar situation and may find it difficult to give orders. Try to find a compromise that everyone is happy with. Make it clear that you want to do your job well – and that delegating tasks to others is part of the job. Remain authentic and lead by example. Try to get your team excited about the project and create a good atmosphere. Think of yourself as a facilitator who is responsible for the results. One rule that really always applies: no matter how stressed you are, treat everyone with respect – no exceptions.

Important areas and basics

You should also familiarize yourself with these defined areas before starting the project:

  • Process planning and scheduling
  • Cost planning
  • Risk management
  • Project controlling
  • Project organization and documentation

The implementation phase – what else should you consider?

Set clear goals

You can only get there if you make decisions and know where you want to go. Discuss the customer’s requirements for the project in as much detail as possible. This is particularly difficult with very technology-oriented projects such as an ERP implementation: the customer often has little idea of the technical possibilities. A good way to present these in an understandable way is to hold a workshop. However, you should not only discuss project goals and milestones with the customer, but also with the team in advance. What needs to be done by when? What are the intermediate goals? Don’t start without a plan, but work out a clear assignment with clear goals, workflows, and deadlines. Read about how to set specific goals and other success factors.

Delegate tasks as a project manager

As a project manager, you often feel like you have to do everything yourself. However, project work should always be a team effort. If you take on too much and cannot relinquish control, you quickly run the risk of becoming overwhelmed. As mentioned above, as the project manager, you should know the strengths and weaknesses of each team member. You can then assign tasks accordingly. Make sure they are completed on time, efficiently, and completely. Be clear about the task and the expected outcome. It is not your job to get involved after the fact, or even to complete the task yourself. Of course, this does not mean that you should not listen to problems. Delegating work has several benefits. It helps take the pressure off you and keeps you from getting stressed. You can focus on your own tasks and give others a chance to learn. You cannot be an expert in everything. Use the expertise of the whole group so that everyone can do what they do best.

Communicate successes and problems

Poorly organized projects can result in work being done twice or not done at all – or you don’t know exactly who is responsible for what. This is not very efficient. Especially when you have a limited time frame. There is a simple solution. Make a list that everyone can see. Your list could include the following items

Who is involved in the project?

  • What is their role in the project?
  • How can they be reached? How do they generally communicate with each other?
  • Who is the contact person for questions and problems?
  • Who has what tasks and when do they need to be done?

When do meetings take place?

  • What will be discussed at the meeting?
  • Who documents what is discussed?
  • Does everyone have to attend the meeting?

When tasks are visually assigned and clearly documented for all to see, people tend to complete them promptly and conscientiously. No one wants to be the person everyone has to chase and can’t count on.

After the project is before the project

Project participants eagerly await the deadline. You might think that once all the phases have been successfully completed, the project is done. However, as the project manager, you still have some work to do. For example, you should document whether the effort has been worthwhile from a business perspective and record any important results.

Conclusion: ERP project management

As you can see, there are several things you can do before the project starts. Even if you have the role of project manager, you do not have to do all the work yourself. The relationship between you and management is especially important. They need to be behind the project and support you when problems arise. Without their support, it will be difficult for you to develop authority over the team. However, do not try to run the ERP project strictly according to management’s instructions. This is very likely to cause problems and resistance from the workforce. Still unsure? Then you could attend training courses or seminars to learn the most important basics before you take over the project management.

Want to learn more about ERP project management or the full range of TimeLine ERP features? Send us a message using the contact form, write to [email protected] or contact our sales team at +49 212 230 35 200. We look forward to hearing from you and will be happy to advise you!

The specification book in the ERP project – implementation of customer requirements

The creation of a specification book – a requirements and functional specification – is usually one of the mandatory tasks before an ERP implementation. Admittedly, creating these two documents is not one of the most popular tasks in an ERP project. They take up a lot of time and resources that are usually needed elsewhere. Time pressure or capacity constraints are often reasons for not creating them at all, or for creating them only very briefly and superficially. The consequences of this approach often become apparent later in the project. Especially for demanding ERP projects, you should not do without a functional specification. It will help you plan the implementation in the best possible way and minimize risks in the project – to name just a few of the benefits. In this article, you will learn why it makes sense to create a specification book, what it should contain, and what else you should be aware of.

Definition – what is a specification book?

The specification book is a document created by the contractor. In the case of an ERP project, this is always the ERP vendor. It is based on the specifications formulated by the client, in this case the customer or interested party, in the requirements specification. In a specification book, the vendor describes, usually in very detailed form, how it intends to implement the customer’s requirements. It contains a concrete description of the solution as well as a detailed work concept and clearly defined target states that have been agreed upon in advance. This document also defines the technical capabilities, functions and configurations of the ERP system that will enable these target states to be realized. In short, the “how” and “with what” is a particular focus when creating a functional specification. It is the “roadmap” for a smooth implementation and provides a framework for the entire course of the project.

 

In addition, the content of the specification book serves as a contractual basis for the collaboration between the customer and the ERP provider and has a legally binding status. It also serves as an acceptance criterion for the implemented ERP solution at the end of the project. As you can see, the specification book has a right to exist. The terms requirements specification and specification book are often used interchangeably, which often leads to misunderstandings and confusion. In fact, from a purely legal point of view, it is very important in which of the two documents something is recorded. If one of the two parties does not adhere to the previously agreed content, the customer and the ERP provider can always rely on the written agreements in the specification book. In this context, it is important to know that all previously discussed agreements between the customer and the ERP provider lose their validity as a result of the requirements specification, unless otherwise noted in it.

You may also be interested in:

What are the benefits of a specification book?

A spec sheet is really used whenever there is a client and a contractor. It is especially helpful for very large projects. In addition to the legal security it offers both parties, it has three other major advantages:

Planning certainty for the customer and the ERP provider

Thanks to the very precise documentation of the target statuses and the necessary work steps, both the customer and the ERP provider know exactly how the project is progressing at all times. This ensures that deadlines are met as closely as possible. In addition, both parties know when the project is expected to be completed and can plan accordingly. But that’s not all – it also helps to keep an eye on the budget. Every adjustment has an impact on the cost, and this prevents it from getting out of hand. The client knows exactly what he is getting for his money and the contractor can calculate his expenses with certainty.

Transparent processes

The detailed written formulation of the solution approaches makes the entire path to go-live transparent. Everyone involved knows where they are in the implementation and what steps are needed to complete the project.

Fewer renegotiations

First and foremost, a well-developed specification eliminates the need for nerve-wracking renegotiations and discussions. As mentioned earlier, both the customer and the ERP vendor can rely on the agreed-upon items in the document at all times – anything that is not in the specification book is not included in the scope of delivery. A follow-up request is created for all subsequent change requests. Subsequent deliveries, changes, and scope creep – the uncontrolled growth of project requirements during implementation – are easily avoided.

You might also be interested in:

  • 3 signs it’s time for an ERP change
  • Implementation with waterfall or agile ERP model?
  • Why does an ERP project fail?

Process – from specification book to functional specification

Typically, the customer or prospective customer writes the requirements specification, and the customer and potential ERP vendor discuss which items can be implemented and how in an ERP workshop. The prospect and the vendor go through the items together and the vendor determines whether they are included in the standard system or whether they need to be customized. The ERP vendor often provides advice on the requirements listed in the specifications. If a requirement does not appear to make sense, or if an additional feature or service would be more appropriate in this context, the vendor will usually make a counter-proposal. The specification book is usually written after the selection of the EPP and at the beginning of the implementation phase. At TimeLine, the specifications are sometimes created during the workshop or shortly after. The points discussed with the interested party are documented and summarized.

projektteam-meeting

Typically, the project manager needs one day for each workshop day for follow-up work. The specification book ultimately determines the cost, i.e. how expensive the ERP project will be in the end. Although it is the basis for the offer, it does not mean that the order will be placed. At this point, other vendors may still be in the game. The prospect can then decide whether the competition may have made an offer that has more features or is simply a better fit for the company. Before the prospect makes a selection, changes can still be made to the specifications. Once the prospect selects an ERP vendor, the specifications become part of the purchase contract and cannot be changed. The prospect orders based on the specifications, and you enter into what is called a letter of intent.

What if the customer wants to make changes?

Especially in large projects, unplanned changes often occur during implementation. But if the customer wants to change something after the fact, the purchase contract changes as well. Each time a change is requested, the ERP vendor decides whether or not the item is still in the budget. If it is not, a second quotation or follow-up order is created. Anything that goes beyond the specifications is a follow-on order. Although the hourly rate remains the same, the customer is in a better position to negotiate if they order more services from the beginning and do not order additional features later.

How do you measure a successful implementation?

Licenses are reviewed with the customer after installation. As far as customizations are concerned, they are not reviewed once at the end of the project, as one might assume. It is more of a process that is done and reviewed on an ongoing and continuous basis, such as weekly or monthly. This is also feedback for both sides as to whether you are still on schedule.

You might also be interested in this:

  • What is an ERP workshop?
  • Why online presentations pay off
  • On-site ERP training – is it worth it?

Structure and content – what should be included in a specification book?

A specification book is used in a wide variety of areas, so standardization is simply not possible. There is no regulation or legal standard that describes what a functional specification should contain, what structures should be followed, or what a functional specification should look like in general. There are, however, various approaches – the following structure has proven effective in software development:

Introduction

It is always advisable to summarize the most important key data for an ERP project. Make sure that all parties involved are explicitly named and that the project is briefly described. Communication channels should also be listed.

Who is involved in the project?

  • Contractor and customer
  • Stakeholders
  • Project team
  • Contact person for questions or issues

Are communication channels listed?

What is the project about?

What is the end result?

  • Description of milestones
  • framework conditions
  • Definition of deadlines (completion, acceptance, deployment)

Any special features of the project

Project goals and non-goals

It should be clear that the goal of the project should be listed. However, there are often items in an ERP implementation that are somehow “docked” to the edge of the project. Therefore, it can be helpful to define the non-goals in addition to the project goals. By explicitly defining which areas are part of the project and which are not, discussions can easily be avoided. By formulating non-goals, the boundaries of the project become clearer and the “gray area” becomes smaller. In this way, you quickly gain clarity about what is “in scope” and what is “out of scope” in a project.

  • What will the project address?
  • What will the project explicitly not address?
  • What problems will the project solve?

Application and product environment

The future use and environment of the product should also be specified in the specifications. This includes the target audience, application areas, business processes that will be affected, and operating conditions.

Features

Make sure that all functions and use cases are described in detail.

  • How and under what conditions does the function work?
  • What is the impact on other business processes?

Services

The services describe the requirements you have for a particular function. For example, the execution time or the accuracy of a calculation. Make sure all services are listed.

Quality requirements

The quality requirements should also be summarized:

  • What are your quality requirements?
  • What does quality assurance, quality control, and quality acceptance look like?

To be more precise, it is useful to assign a quality level to certain characteristics, for example

  • Changeability = not relevant
  • Efficiency = good

User Interface

Basic requirements for the type of layout, dialog structure, or access rights should be listed here.

Projektteam Meeting

Other and special requirements

Dazu gehören zum Beispiel die Dokumentation, Buchführung oder Sicherheitsanforderungen wie der Passwortschutz.

Technical requirements

The technical equipment required for the implementation should be listed here. It is useful to list the software and hardware systems that need to be installed for the application. This is important, for example, to ensure the availability of the network connection.

  • What equipment do you need for what task?

Interfaces

All existing systems, products and interfaces should be listed here. This is important to be able to connect the product to all other applications. Are there already project-related systems and/or products that do not need to be implemented by the contractor?

Problem analysis

The most important problems and perhaps also those that are to be expected should be summarized here. A solution approach should be available for the most likely problems.

Project development

This item should describe as precisely as possible what steps are planned at what time and how the entire project is organized.

Testing and acceptance

Tests check the product for functions, features and quality before it is completed. If the product runs without errors, it can be declared complete.

  • What conditions must be met?

This is just an example of what a specification book can look like. Some criteria are essential, others are important but not critical. Still others are desirable but can be left out. Which features are “must haves” or “nice to haves” will vary from company to company. Just make sure they are clearly identified as such. The level of detail can vary, but the technical requirements should be described in great detail. Ultimately, it is important that the requirements from the specifications are consistent with the statements in the specification book and that there is no room for interpretation. The requirements specification should be well described and documented, leave little room for interpretation, be specific, and include a necessary cost estimate. As a rule of thumb, it should leave no questions unanswered and an outsider should understand what is meant.

You may also be interested in:

  • As a user, how can I recognize a good ERP system?
  • The process of a successful ERP implementation
  • Success factors for a flawless ERP implementation

What else should you be aware of?

From the customer’s point of view, you should first take some time to look at the specifications carefully and not just wave them through unread. Pay particular attention to the interpretation of your requirements and check that they have been implemented according to your wishes – simple, but it can save you a lot of trouble later on. In addition, there is always the risk that you will ignore the current situation in the company when writing the specifications. This means that you miss the opportunity to take advantage of the potential for improvement offered by the new system. Use the ERP project as an opportunity to take a critical look at your workflows and business processes – this will help you realize the potential.

Meeting eines Projektteams

From the ERP vendor’s point of view, it makes sense to invest some time in development, to coordinate in detail with the customer, and to leave nothing unresolved. If questions remain unanswered, if you are looking for an answer, and if there are bottlenecks, clarify this with the customer immediately. It is important to be as accurate and detailed as possible when writing the report. It is also a good idea to use plain language and avoid using technical terms. Many different people will read the specifications – not all of them will have a deep technical understanding. Graphical representations are also a good way to communicate complex content in an understandable way. Use diagrams, tables, or mind maps to visualize the customer’s requirements and make them as easy to understand as possible.

Conclusion

Creating a specification book is a necessary step in minimizing the risks of an ERP project. On the one hand, it serves to fulfill the requirements listed in the specifications and to plan the implementation in the best possible way so that there are no nasty surprises at the end. On the other hand, it helps to validate the implemented solution at the end of the project and to protect both parties. It is particularly important to know the difference between specifications and requirements. Legally, it makes a big difference which of the two documents defines something.

If you would like to find out more about requirements analysis, specifications and functional specifications or the full range of TimeLine ERP features, please send us a message using the contact form, write to [email protected] or contact our sales team at +49 212 230 35 200. We look forward to hearing from you and will be happy to advise you!

These tips will help you with your ERP selection

Today, a well-functioning, customized Enterprise Resource Planning ERP system is essential. Used correctly, it can be the hub of your business – a central place where all your business processes converge and can be coordinated by you. But getting there is not always easy. The task of finding the right system for your business can present you with one or two challenges – choosing the right ERP vendor is one of them. The complexity of the market is often underestimated. It can be very confusing, with a number of ERP vendors offering systems for different use cases. Each software has its own strengths and weaknesses. Is it any wonder that many decision-makers are already overwhelmed at this early stage of the project? To make the ERP selection process a little easier, we have compiled the most important information about the selection process for you.

ERP selection made easy – getting there step by step

The entire ERP selection process usually involves a great deal of organizational effort and requires careful preparation. The process is divided into several stages. The search for a suitable ERP provider always begins with a requirements analysis. The results are usually recorded in a requirement specification. The creation of a longlist and a shortlist is also crucial for a structured process. The first step is a broad search to identify all potential ERP vendors. In each subsequent step, the number of candidates is reduced according to an elimination process until only a handful remain.

This approach means that you are not immediately overwhelmed by the flood of ERP vendors, but have the opportunity to filter by certain characteristics and then make a decision. This may sound like a long and unnecessarily time-consuming process. Keep in mind, however, that you will get to know each of the remaining candidates personally during an ERP workshop before the actual ERP selection. It is therefore in your best interest to start with a short – but high quality – shortlist. So far so good – but how does it all work?

You may also be interested in this:

  • Why is requirements analysis important?
  • The requirements specification – a guide for the customer
  • The requirements specification in the ERP project – implementing the customer’s wishes

Starting with a longlist

Now you have read the term ‘longlist’. But what exactly is a longlist? The name gives it away a bit. A longlist is a popular and efficient tool for ERP selection. Basically, the goal is to reduce the large and confusing range of products on offer to a manageable level so that you not only find it easier to make a decision, but also to make the right choice for you in the end. The first step is to get a general idea of the ERP vendors and options that are generally available, and to eliminate those that do not meet your key selection criteria.

Where do you find potential ERP vendors?

There are several approaches to finding potential ERP vendors. The most common method is probably a simple and targeted Internet search. A vendor’s website will give you an initial overview and provide you with information that you can use to create your longlist. However, the downside is that most websites only list the most important functions and features, and you may not be able to tell if the provider can meet your specific needs. In addition to researching on the Internet, you can also find information in trade magazines or by attending trade shows and events. The latter has the great advantage that you can get to know the provider personally and form a first impression. You should never ignore the interpersonal level when choosing an ERP.

The World Wide Web as a first stop

More and more vendors are offering live webinars to give prospective customers a first look. Similar to a trade show, this makes it easier for you to assess whether you should consider working with the ERP vendor. Comparison sites can also be a valuable tool in your search. They allow you to filter a large number of ERP vendors based on specific criteria, giving you an initial overview. However, it is important to ensure that the platform is independent and neutral. Regardless of how you search for potential candidates, you should always keep in mind your ultimate goal of finding an ERP system that is right for you. The following questions can help you determine whether or not a candidate should be on your long list:

  • Does the ERP system meet your most important requirements?
  • Which of your non-functional requirements does it meet?
  • Does the ERP vendor specialize in a particular industry, perhaps even tailored for you?
  • Are there any criteria that rule out the vendor?

The point of this step is not to analyze every ERP vendor in detail. A cursory review is sufficient at this stage. If an ERP vendor meets the most important requirements, you can add it to your collection. The result of your research is a list of potential ERP vendors, called the longlist.

You may also find this interesting:

  • ERP implementation cost drivers
  • Implementation with waterfall or agile ERP model?
  • Why does an ERP project fail?

Reducing and filtering – how the shortlist is created

The first part is done. You now have a list of ERP vendors that are generally of interest to you – but you have not investigated them further. The next step is to separate the wheat from the chaff and take a closer look at the candidates. But how do you do that? What criteria should you look for? This is where your specifications come in. Send them to all the ERP vendors on your long list. Briefly describe your requirements and ask for an initial assessment. Of course, the primary focus should now be on whether the ERP vendor and its software are a good fit for you and can implement your requirements. But don’t just pay attention to the technical content of the answers; the soft factors in particular will give you valuable information about your potential partner. The following questions will help you in your evaluation:

  • How long do you have to wait for a response from the ERP vendor?
  • Do you get a standard response or does the vendor respond to you personally?
  • Is the communication at eye level?
  • Does the feedback provide value to you, or does it feel like a sales pitch?

Don’t underestimate interpersonal relationships

The interpersonal relationship is often underestimated, but it is essential for successful collaboration. If you do not get along with the provider on a personal level for some reason, conflicts are often inevitable. You can now use the reactions of each vendor as a reference point to eliminate further entries from the list. Your list should now contain only ERP vendors that meet your required priorities and also score high on the soft factors. In a best-case scenario, you will be down to two to four ERP vendors.

If your shortlist is still significantly longer at this point, you should filter a little more ruthlessly. As mentioned above, the last step before the actual ERP selection is a multi-day workshop in which you take a closer look at each of the remaining vendors. These take up an enormous amount of resources, and the project team in particular is tied up during this time and not available for day-to-day business. So try to thin the list as much as possible and move on to the next phase with the shortest possible shortlist. After all, every provider you eliminate in advance will make the next step much shorter.

You might also find this interesting:

These tips will help you with your ERP selection

Narrowing down the vast array of products out there sounds easier than it is. After all, all vendors put their best foot forward, and you really need to do your homework to determine who is the best fit for your business. The following tips can help you find your way through the ERP jungle:

It all rises and falls on precise requirements

Many companies see an ERP system as the solution to everything that goes wrong in their business. However, this approach is misguided and not based on reality. At least not completely. Even if you are aware of the problem, very few people think about what a concrete solution to this problem might look like. Of course, an ERP system can significantly improve processes, but first and foremost, it is and will remain a tool that will only benefit you if it is used correctly. So try to define your requirements and goals as specifically as possible. Maybe you already have a solution?

Limit yourself to the most important functions

Let’s get one thing straight – you probably won’t find the perfect ERP system for your needs. Each has its pros and cons. What is an important feature for one company may be out of place for you. However, many companies hope that the solution will solve all their problems, offer many features, streamline processes, and do so with as little effort as possible. If you don’t prioritize, ERP selection can become an endless search. You may even miss the best solution for you. To avoid a long list of requirements, declare the most important items on your list as “must-haves” and consider whether the rest are essential.

ERP selection with an eye on the future

What is wrong now should be fixed, or at least that is the motto in many places. This approach is understandable. But don’t forget that a business is constantly evolving. In most cases, an ERP system will be with you for many years, so it is not wrong to consider future developments. What challenges might you face in the near future? Think about your needs today and in the years to come.

Seek a personal meeting

It is often difficult to evaluate an ERP vendor based solely on its website. You will soon realize that this is much more informative and will help you to classify your counterpart. Remember that you are not only buying the software, but also services such as training or consulting. This is why soft indicators also play an important role in ERP selection.

Ease of use is an important consideration

No matter how great the system is, if it is difficult to use on a day-to-day basis, it will only harm motivation and reduce productivity. That’s why there are features that don’t interfere with processes, but make the daily work of software users much easier. These include easy-to-find controls, intuitive user interfaces, and customizable views. Many vendors show screenshots of the user interface on their websites. While this can give you a good idea of what to expect, the usability of an ERP system is more than just how it looks. Keep this in mind as you consider your options.

Be open to solutions

At its core, ERP selection is about finding a concrete solution to existing problems. So try to focus on what you want to achieve, not what you have to do to get there. Be open to different approaches and formulate your requirements in a neutral and process-oriented way. Limit yourself to describing the problem and formulating your desired goal. How this is ultimately implemented is best left to the ERP vendor.

You might also be interested in this:

  • Corporate ERP training – is it worth it?
  • How can I, as a user, recognize a good ERP system?
  • Why online presentations pay off

Conclusion

The choice of ERP should be carefully considered. After all, it is a complex piece of software that interferes with your business processes. Many companies cannot say exactly what they want from an ERP system and therefore find it very difficult to make a decision. Of course, it is not easy to find your way around the wide range of vendors and features, but it would not be wise to just pick one without thinking about it. It is always worth comparing. Try to set clear priorities and focus on both the current situation and the challenges you expect to face. Then nothing will stand in the way of a successful selection process.

To get a first impression of our software, we offer free webinars on a regular basis as well as various events. If you would like to learn more about ERP selection or the full range of TimeLine ERP functionality, please send us a message using the contact form, write to [email protected] or contact our sales team at +49 212 230 35 200. We look forward to hearing from you and will be happy to advise you!