Publications
:
It feels like every month, there’s a new story about a company dealing with major ERP failure and implementation problems. The latest edition comes from candy maker Haribo, who had troubles getting their famous gummy bears out to suppliers in late 2018 because of problems stemming from their latest ERP integration. Haribo expected to have a few issues during implementation. But, by their own admission, the supply chain issues they faced after deployment were much larger than anticipated. For Haribo, the problems eventually sorted themselves out. But other companies haven’t been so fortunate. Let’s take a look at a few other examples of failed ERP implementations and the key causes of their failure: Woolworths Australia, 2015 After 6 years of planning, Woolworths Australia (or “Woolies”) went live with their new ERP in 2015. They had problems almost immediately, the biggest of which was empty shelves in many stores. What caused the problem? A glitch in the new system prevented Woolworths from placing orders with their suppliers. Suppliers were frustrated and furious… and Woolworths lost millions of dollars in sales. But that wasn’t the only problem with the new ERP system. From the Australian Financial Review (AFR): One of the key problems and failings that occurred at Woolies during the SAP implementation process was the lack of attention given to documenting processes used by staff in the day-to-day running of the business. Too much of the intellectual property of what was then the best-performing supermarket group in Australia was left in the heads of people who worked at Woolies. This carried lots of risks because when people left they took with them key pieces of information. Loss of corporate memory is often referred to as a key risk in companies but it is only when something as critical as a new merchandising system is jeopardised that senior management learn its importance. What can we learn from this? Companies need to map all their business processes prior to ERP implementation. This practical information is essential when designing the new ERP system. Every company should have a plan for employee knowledge transfer so that information doesn’t disappear when an employee leaves the company. Above all: test everything before you go live with a new ERP system. Oriola Finland, 2017 Almost every ERP implementation will have a few hiccups when the new system goes live. But what do you do when a small hiccup in the supply chain can mean the difference between life and death? This was the problem Oriola Finland was facing in September 2017, when they launched their new ERP. Oriola is one of Finland’s largest pharmaceutical suppliers. They deliver thousands of medications to pharmacists around the country, including insulin, cancer medications and anti-psychotics. Any disruption to the supply chain doesn’t just cause lost sales: it can cause great damage to people’s health. It sounds like Oriola didn’t anticipate any supply chain disruption as they switched over to their new ERP. But in reality, their ordering system was shut down for days. This led to widespread confusion and frustration as pharmacists all over […]
WHAT IS THE MOSCOW METHOD (MoSCoW Prioritization)? The MoSCoW method is a technique that helps categorize and prioritize all requirements that define a “future state”, that should be implemented. The method was developed by Dai Clegg in 1994, and dedicated to supporting software development projects (where the “future state” is the shape of an application that should be implemented). Despite the origin, the method is not only limited to software projects, and can include requirements necessary when implementing changes to physical products (cars, buildings, furniture) or organizational changes (eg. changes to the bonus systems, changes to the partnership agreement, etc.). Although this is a generic method, it is mainly used when implementing software systems and helps companies define the requested configuration of a future application that is planned to be implemented. The MoSCoW name explained The MoSCoW term is an acronym inherited from the statuses used in this method to prioritize requirements: Must have, Should have, Could have and Won’t have. Priorities used in the MoSCoW methodology The priorities used in the MoSCoW method sound self-descriptive, but in practice, they need some additional explanation to use them properly and in a consistent way: Must Have (MUST) – This is the most obvious priority that represents the critical requirements that must be delivered from day one. The software without these requirements simply can’t be used properly and the project goals will not be achieved without them. Should Have (SHOULD) – This priority represents the requirements that are almost as important as “Must haves”, but users can live without them. Although it sounds similar to “Could have”, they are closer to “Must haves”. The difference is, that while “Must haves” have to be implemented from day one (software can’t exist without it), software users can live without “Should haves” for some time. The “Should haves” have to be ultimately implemented, but the company can live without it and still benefit from the 1st version of the software solution; these missing requirements will not cause critical security problems or will not bring a lot of additional work – if that happens, it means that they should be classified as “Must haves”. The “Should have” priority is often used to divide a complex project scope into phases, where only “Must haves” are implemented in the current phase, and “Should haves” are planned for the next phases. Sometimes, companies use “Should have” to address the “readiness” for future requirements or improvements (e.g. currently the software is not implemented in the cloud, but it must use the technology that is ready for future cloud deployment). Could Have (COULD) – This is used to address all the “nice to have” features, that will have a positive impact on the final solution (and then on users’ satisfaction/efficiency), but are not necessary and might never be implemented. Their business value is smaller than “Should haves”. These requirements are useful when comparing software from various software vendors – assuming, that all “Must have” and “Should have” requirements must be identically fulfilled by all short-listed applications, “Could haves” help […]
Legacy systems implemented in old technologies can cause serious problems when integrating with cloud systems. In this chapter, we discuss the obstacles that might appear in the context of legacy systems when migrating to IFS Cloud and switching to OData API. To provide you with a wider perspective, we interviewed Paul Phillips, Vice President of Product Management at Novacura. What is OData API? OData (Open Data Protocol) API is a standardized protocol for building and consuming RESTful APIs, which allows applications to interact with data over the internet in a consistent and interoperable way. Developed by Microsoft and approved as an OASIS standard, OData enables the creation, reading, updating, and deletion (CRUD) of data through a uniform and predictable interface, making it especially useful for data-centric applications and services. The new IFS OData API is a revolution especially for all the legacy systems integrated with previous IFS versions (that currently use PL/SQL API). Could we start with briefly defining the areas in which the problems might appear? The problem is definitely much wider, and it is not just limited to replacing the integration logic and calling the new set of API objects and methods instead of the old ones. For the legacy systems, there might be additional technical or organizational barriers, such as: No support for OData protocol: The technology used in many legacy ERP systems doesn’t support the OData protocol, which complicates integration with legacy systems. No state-less philosophy in the legacy system Synchronous communication expectation Technical Limitations: For successful integration with legacy systems, compatibility with HTTP(s) protocols, connectivity, and security requirements must be addressed. Some legacy systems may require additional support for cloud-based operations. Organizational Challenges: Legacy system management is further complicated by limited documentation, lack of source code, and a shortage of resources knowledgeable in how to integrate legacy systems with modern platforms. These barriers are common when organizations seek to connect legacy systems to new cloud infrastructures. All the topics mentioned above sound serious, and definitely require additional clarification. Let’s focus on them all one by one. Could you start from the beginning and tell us a bit more about the lack of support for OData in the legacy system’s technology? When we think about legacy systems, we usually think about old systems built 10-20 years ago as hard-coded software programs, written in C / C++, Visual Basic or even more specific technologies (eg. when we think about specific machinery integrations). These systems were designed before the cloud computing concept has been introduced and the OData standard was defined. It might mean that there is no ready-made OData library for the technology used to implement the legacy system. All the common OData foundations (that reside below the business layer added by IFS) must then be implemented manually, which is a large additional cost of adjusting the legacy system. Keep in mind, that even if the OData support libraries exist for the language used to implement the legacy system (eg. C++), this library might be incompatible with the particular framework used to build the legacy system, […]
The main goal for any industry is to use the ERP system in a more productive way to make it more competitive with other companies. How to perform a successful ERP implementation and plan the right framework for the entire project can raise many questions (...)
I’ve been selling standard software for 30 years now and in my experience, when you implement “standard” software, it’s very seldom that you actually implement it without any changes. The same way in an organization, some processes are easier to call standard processes. But there’s always an angle on whatever a single customer is doing there. And in many cases, some customers are actually bending backwards to accept the standard process. And they’re doing it for the wrong reasons. They think it will be effective when instead they’re actually causing commotion and disturbances in their own employees and organization. Your business processes are like a car. All cars start with the same pieces. But within that standard process are a million variations: color, size, motor, etc. They might all start from the same basic pattern, but the end result is meant to be tailored to the driver. Does your company need a Volkswagen or an Audi? Only you know for sure. Take maintenance processes for example. When you actually implement a standard process, you need to have the organization aligned with that process: not just management, but also the people who carry out the process. When one of our customers started optimizing their maintenance processes, they agreed at the management level: “this is how we would like to steer our maintenance operations in our group”. But the way they were organized on different sites was contradictory to what they wanted to achieve. There were people in the company with responsibilities and roles that didn’t exist in their new “standard” processes. And these people had vitally important jobs: they were definitely not redundant. This isn’t an isolated incident. It’s a typical discrepancy between how a wished “to be” scenario has not been aligned in reality—to the “as is”. If you look at any given company now, you will have as-is situations in every standard process: How do we do purchasing? How do we retrieve goods from the warehouse? How do we create a fault report? How do we invoice? But depending on how the company is organized, they could have split up the processes in many roles—or merged many roles into one road. If they’re not careful, they can put things upside down, in many cases. So I want you to challenge the idea of “yeah, we have a standard process for this. Yes, we have the best practice for this.” It’s not as simple as just saying an idea is a best practice. Why? Because there’s no such thing as a standard process. There’s only processes that work and processes that don’t. So, what can you do to make your processes better? Don’t assume that one standard process works for every situation. In the example mentioned above, the customer was already using Novacura Flow. With Flow they could see that each site was carrying out the same processes but in different ways. You see this a lot in maintenance. Sometimes one central maintenance department serves every area of the site. Sometimes you have different maintenance areas depending on the process. Some companies have […]
ERP upgrades are necessary, but not necessarily fun. You have to keep your systems up-to-date to cut down on security risks and keep your business running efficiently. But upgrading an ERP can also be expensive and time-consuming. Novacura has performed many, many ERP upgrades for our customers over the years, and we’ve got the ERP upgrade process down to a science. Some clients have even gone as far as to say the process was fun! So I asked Johan Ekerstedt, Project Office Manager at Novacura, to explain our ERP upgrade pre-study process and how it helps companies maximize value while minimizing frustration. Step 1: the audit We start with an audit of all the company IT assets, processes and systems. This includes looking at previous development work, ERP customizations, and more. The audit gets everyone on the same page with regards to what IT assets you already have, and what you need to add, remove or change in order to be as efficient and productive as possible. It also helps everyone start from the same source of truth – and identify places where processes (and data) can be better. Many companies are really surprised at what we find during the audit. Sometimes during the audit you find things that change the scope of the whole project that no-one knew was there. Johan Ekerstedt Novacura, Project Office Manager IT architecture is complicated, and it’s easy to lose track of items as time goes on. This is why we always start with the audit. Step 2: process workshops The second step is a series of workshops with the customer. In these workshops, we ask your ERP upgrade team three very important questions: Which processes do you want to improve? How do you do these things right now? How much change do you want to make? “This is where it gets interesting,” says Ekerstedt, “because inevitably people find that they’re not all doing things the same way.” This is especially true if your business has multiple sites, or operates in different countries. We start with the process that’s causing the most headaches. From there it’s a matter of modeling the process, mapping out all the variables, and creating a workflow of what you want the process to look like in the future. Which processes do our customers usually want to start with? It depends. I can’t say there’s one common process that most companies want to start with. It depends on the business they’re in. We usually start with the process that the customer says is their biggest pain point. Johan Ekerstedt Novacura, Project Office Manager Some of the common paint points our customers have include: removing previous ERP customizations to make updates/upgrades easier in the future switching from on-prem to cloud making the ERP integrate better with other software making the processes in the ERP match the way people actually perform the process Step 3: the project plan With the results of the IT audit and process workshops in hand, it’s time to define the project plan. […]