I have long-standing relations with ERP systems. I used to be an engineer rolling out complex software at several manufacturing enterprises. I know the specificity of ERP projects implementation and even have a scientific publication dedicated to optimization of manufacturing equipment loading. In this article I share my knowledge about different aspects of developing and integrating resource planning software.
- Basic terms and concepts of business management software
- How to roll out an ERP or business management system
- Reasons and how-tos for taking an agile approach to ERP integration
- Estimating ERP project costs
- Applying the principle of simplicity to ERP software implementation
I hope this guide will give you useful insights on how to build your own ERP system that will help your business grow and succeed.
What is ERP (enterprise resource planning)?
Before we get into the topic, let’s clear up a popular misconception about what does ERP system stand for.
Many people use the ERP abbreviation in a broad sense. When our clients mention ERP in their project descriptions, they usually mean a business management software not necessarily related to manufacturing, resources or planning.
However, ERP (enterprise resource planning) in the pure meaning of this word is a standard for manufacturing enterprises which extends another standard called MRP II (manufacturing resource planning). As a standard, it covers multiple types of planning that should be implemented at manufacturing enterprises. There were 16 planning types mentioned in the standard when we used to work with it, and I am not sure how many are described there nowadays.
I mention these planning types because they help me to make it clearer:
The main purpose of an ERP system is planning.
Most of data entered in the system is used to build multiple plans including capacity planning, bill of materials and master production schedule.
This is the main difference between an ERP system and business management software in general. In many companies, business management software covers a relatively narrow range of tasks, such as HR management, orders management, time tracking, etc. And its main purpose is not planning but tracking.
Here is a short real life story to illustrate how tracking works in business management systems. Once we installed a typical accounting system in a small store. The store was managed by two people - a store owner and a shop assistant.
A couple of days after the system was installed, we returned to make sure that everything was working properly. The owner said that he had found a missing item in the system that morning. It was a bag of potato chips or something like that. The software was saying that the item should be there, but it wasn’t there actually.
Confronted by this fact, the shop assistant at first denied involvement, but then repented and confessed. I am not sure what happened after the owner found a missing sale item - probably, nothing. But what I have learned from that story is the importance of the tracking process.
A small store, with only two people working there, is a very indicative example. Not too many sale items, but apparently the owner didn’t know the state of his stuff. Two days after he got an accounting system, he knew that. He could track routes of wares and money. Therefore, he could be in control of the whole business.
Long way to planning
Most business management systems never grow up to be a planning software. Some of their workflows are similar to those in ERP, but their purpose is different and so is their size. It is obvious, but it helps to highlight that an enterprise resource planning system requires an enterprise.
An enterprise is bigger than a company having about 100 employees. It has many departments that need tracking of their activities. It requires implementation of a huge variety of workflows.
An average company usually needs a software to automate one or maybe two workflows. The rest of activities can be paper-and-pencil due to simplicity purposes. A software created for such a company usually has two types of processes implemented:
- tracking processes;
- reporting processes.
An ERP software has both of these processes and also incorporates multiple planning processes.
- ERP systems can add a great value to large manufacturing enterprises.
- For small businesses, it makes sence to utilize a smaller management system with a set of features narrowed to their specific needs.
- Benefits of a full-scale ERP system would not work out for an organization with less than 500 employees.
Since our company specializes in building software systems for mid-size companies and startups, I'll pay more attention to business management software systems for small businesses rather than to the ERP standard.
However, in terms of development and rolling out, both types of projects are somewhat similar. Enterprise resource planning software is bigger, but the process of ERP development and rolling out is applicable to smaller systems too. In the next sections, I will focus on these similarities and share my experience to describe proven ways to successfully develop and integrate management systems for businesses.
Many business owners do not have a clear vision of how to roll out a new ERP system. They focus on development instead of solving business problems. Then, when it comes to launching the product, they rely on a "magic" behind software development that should integrate the software into their workflows.
When I was an ERP roll-out engineer, my job was to help people launch different automation systems. Albeit these products were promoted as ready-to-use, they often were not tailored to specific business needs, users appeared to be not ready to use them out-of-the-box, reports were not good enough. As a result, the customer needed someone to help with that. The ERP infrastructure produced me, a roll-out engineer - a specialist who could get into the company’s problems, customize the product and eventually launch it.
As it is mentioned in the previous section, ERP systems are more specific software than many people think, but general principles of rolling it out are the same as for smaller management systems. Let me briefly describe what an owner of this type of project should deal with when going live.
Not a long time ago I had a conversation with one of our ex-customers who wanted to refer a project to Anadea. The project was a complaints management system meant for government ministries in his country. They arranged a request for tender and the referrer wanted us to apply to it.
He said that the government wanted the selected developer to be present at their offices to do the job. I felt some misconception about what he understood by "doing the job" and decided to clarify.
"Our developers are developers", I said. "They are focused on their tasks. They are not taught to be roll-out engineers, gather requirements from people, teach them to use the system and so on. We can develop the system. But we need a person on the customer’s side to do all the above".
He did not understand. He asked if we could hire such a person and do all work ourselves. So, I had to explain the difference between roles of Business and Developer.
I said, "The government will have to give that person an appropriate power. It would be better if the manager was someone from their community. This way, he would know many aspects of the everyday activities at the offices. He would be a field expert".
In fact, not investing in the internal implementation team is one of the most common mistakes businesses make when implementing an ERP system:
So, let’s conclude that there are two different roles - Developer and Business - which are focused on different tasks and have different responsibilities. Now I will explain why the developer should not take on the responsibilities of the business.
Once I rolled out a paperflow automation system at a branch of Ukrainian Ministry of Agro-industry. It was the toughest project I ever launched. It took a year to go live and all of us who worked there felt like torn to pieces eventually.
At the same time, all our projects rolled out at private companies and enterprises were successful. The reason was the absolutely different attitude on the part of the customer.
Owners of private enterprises:
- pay their own money;
- are interested in success;
- try to get bigger value for less investment.
On the contrary, government organizations:
- do not pay out of their pocket;
- interested in starting a project as long as they get part of the funding provided by the government;
- do not give a damn to the project value after it is started.
I am telling that not to provide another opportunity to criticize the government, but because there is something a project owner can learn from this. Here is what I would like to highlight:
There is an explicit dependency between success of the project and how much the customer wants to do for it personally.
That sounds too obvious, doesn't it? Let me be more specific. To successfully launch a software product at an enterprise, the owner should assign (or hire) a manager. He can be that manager himself if this work is too important to allocate it to anyone else.
That manager can be called a "business lead" or a "head of roll-out" or whatever. At Anadea, we call this person simply a "customer" because for us he is the main person to collaborate with.
That type of managers have specific responsibilities at their company. They should:
- be personally responsible for success of the project;
- gather requirements from all departments of the enterprise;
- give assignments to the camp of development;
- have power to penalize employees who sabotage the roll-out;
- maintain the rolled out software full-time.
Obviously, such a manager cannot be an employee of the software development company. Developers come and go while the head of roll-out should stay at the enterprise after the software is launched. He should have a real interest in getting maximum value out of the management system and enough power to ensure seamless work of the product.
We did not have that manager when dealing with the Ministry of Agro-culture. It led to a great disaster. The executive who was the mastermind of the project disappeared right after work was started. I was left face to face with several employees I had to force them to use a new paperflow automation system.
Imagine the situation I found myself in. I could gather requirements. I could customize the system and write code facilitating work of the Ministry. I could teach people to use the software.
But nobody cared. Employees thought I was there to give them additional work and potentially replace them by a software (what nonsense! but employees at enterprises tend to think so). The head of the department was 8 months before a retirement, so she did not want any problems to appear until she is out. She explicitly asked me not to trouble her before that time!
I couldn’t force anyone to anything because I was not their chief. The real chief was away all the time. Eventually, he got a promotion and moved to another Ministry. The new head did not know anything about the project.
Oh, yes! They had an IT department. But they were very busy with receiving and printing emails, so they could not help me in any case.
It is worth mentioning that the project could not be ceased. My company signed a contract with the government and received a prepayment, so ceasing a project could draw us into a real trouble.
Ouch. More than 8 years have passed since that but I cannot mentally return to that point in time without feeling despair. It took a year to somehow finish the project and sign all required work completion certificates.
They called me on my cell phone two years after the project was rolled out and asked how to move old documents to the archive. By that time I worked at another company and I could only suggest them to forward this question to their executive manager responsible for automation software.
In projects that involve business management software development and integration, customers tend to transfer responsibility to software engineers. In their turn, developers prefer to solve all problems by writing more code. This is how they see the life. Obviously, not all problems can be solved that way.
In particular, writing code does not help when it comes to rolling software out. Top managers of manufacturing enterprises with ERP systems know that the amount of work needed to install the software and teach the staff to properly use it is greater than the amount of software customization. They know they will have to live with the automation system after the developer completes the customization and switches to other projects.
The same is valid for projects smaller than ERP. When a project owner wants to integrate a business management software in their company, the best result is achieved when the company forces the development camp to solve their biggest problems in the simplest way possible. By the way, this is exactly what the agile software development principles recommend.
ERP implementation team members on the client's side should show a real interest in making their business more productive and be ready to do whatever it takes on their side.
There is a very effective iterative approach which can be applied when rolling out a management software. The next section of the guide dives into ins and outs of this approach.
In this section, I would like to combine two different subjects - ERP integration and the Agile approach - because they work well together.
Let’s start from a learning metaphor. Integration of a business management system has something in common with how a human learns new skills. As a result of management software integration, the enterprise being automated gets new workflows, starts relying on new reports and changes roles of some departments - this is very similar to a human getting professional expertise.
The enterprise is learning new "habits". This process requires gentle treatment. Thinking about it, I can see parallels with my hobbies. I like guitar and martial arts; in both areas teachers arrange lessons in an order that helps a student to learn new techniques and then immediately integrate these techniques in their improvisational activities. If you have another hobby, you may see the same methods applied by those who teach the stuff.
Now let me move to the ERP subject and go through the process of step-by-step software integration.
From development to integration
There is a commonly used procedure suitable for custom business management software roll-out. The procedure assumes that the project should evolve in stages or so called releases. Every release includes the following steps:
- development of a specified set of features;
- immediate roll-out of the set of features;
- receiving user feedback.
So, we are talking about the same loading - integration approach again. The first activity should be performed by the development camp, the second one - by the customer. The feedback should be processed by both sides. As a result of the processing, a new set of features appears and the three steps are repeated again.
Very often, roll-out and collection of feedback appears to be more effortful and valuable than the development work. "Applying techniques" takes more time than "growing muscles".
This is a nature of ERP integration that should be acknowledged by any enterprise or customer who is willing to set up a management system.
Do things effectively
Those who have experience working with agile projects could notice that the procedure in the previous paragraph is very similar to practices recommended by the agile software development methods:
- the whole process is split into releases;
- feedback plays a significant role;
- the procedure is repeated until the desired result is achieved.
Now let's remember what the agile authors say and think about how we can make the whole process more effective. The approach recommends:
- starting with a small investment and adding more resources as the integration progresses;
- building the core architecture as part of the very first release;
- making releases often. From our experience, development cycles from 2 to 4 weeks long work best because they allow the developers to keep related information actual and make small adjustments on the fly;
- moving the most essential features to the beginning of the plan. This recommendation assumes either moving features to earlier releases or making them a higher priority within the current release.
Some other areas of business
The approach described above is not only applicable to ERP or business management systems integration, but also to other custom projects that assume input from users.
A good example of our successful custom project that incorporated the agile methods is eBookingServices. Its owner Robert Den Hollander did amazing job launching the project in stages. Positive experience is always worth to share.
The trick is that the project is a collaboration platform. Collaboration platforms are similar to social networks. Customers who develop such projects should overcome a network effect. It means that the software becomes valuable for users after it already has users - but how to get first participants? And how many people should be brought to the system before new visitors will come and join it voluntarily?
I still wonder how Robert managed to do that. I do not know where he took first providers and clients. I just know that he hired at least 40 to 50 managers to make cold calls, perform content management, posting new deals and be ready to resolve issues.
At the same time, he had only 2 (two) developers! His project management style was very strict. He requested only features he considered essential which helped us to make releases often.
This illustrates a functioning proportion of how much development is required to launch a project compared to the amount of integration work. Very often, projects that appeared to be unsuccessful simply lacked releases and feedback or their development iterations were too long.
When talking to new customers, I often feel that my mindset is different from theirs. Usually, they know what they need from development very well. But they are not aware of how much effort the job requires in terms of management.
I hope this article helps people effectively arrange things when developing and integrating ERP systems or another custom software. Let’s repeat what we have learned so far.
Project owners have their own responsibilities which can be even more significant than responsibilities of the development camp.
One of their main responsibilities is to decide what is valuable and what is not from the business perspective.
It is very appropriate to follow the agile principles while rolling out a management software. In other words, it is reasonable to grow the project in stages, collect feedback and make adjustments in the plan.
In the next section we will talk about planning game and about nature of estimates customers receive from the camp of development. I hope to present some interesting stuff, so stay tuned!
I have already written a few articles about project estimation because fair estimates are an essential question all project owners are concerned of. I really hated to watch the interview after it was published - first because of my horrible accent and second because my understanding of estimation refined since the video had been recorded.
The good news is that now I myself have a better understanding of what is called "fair estimation". I feel that I can share my vision with project owners and give them quite good insight on how to "read" estimates provided by their development camps.
More than a collection of features
Many clients looking for custom ERP development ask to provide a breakdown before starting a project. They assume that a project is a set of features; hence the developers can split the whole work into user stories, estimate every feature separately and calculate the number of days needed to implement the entire project.
Those who have read the previous part know why the statement above is not true. A usual procedure of launching a business management software consists of a) development, b) integration and c) feedback. So, development work (which is often mistakenly considered a merely technical thing) is only part of the big picture. Moreover, this part constantly changes depending on the feedback.
If you ask your developers to break the entire project down into features, they will do that. But can it be considered a fair breakdown? No, it cannot as it does not contain integration procedures (which have significant influence on the timing) and does not take into consideration user feedback.
A fair breakdown
There is a much better way to learn the work scope. Since there are three major activities in every project, an indicative breakdown should refer to all of them. From my experience, it looks very natural when a breakdown consists of development cycles, for example:
- Contracts (establishing relationship between retailers and suppliers) - 2 weeks;
- Price management and retailer order creation - 4 weeks;
- Order finalization and invoicing - 4 weeks;
- Order management reports - 4 weeks.
This type of breakdown looks like a roadmap and is easier to comprehend. Besides, it allows adding and describing integration procedures in between paragraphs. For example, after the first development iteration called 'Contracts' the project owner can invite retailers and suppliers to the application so that they could create their profiles. After the second release ('Price management'), retailers are able to see actual pricing and place their orders online. It means that the project is to start providing value to its owner only 6 weeks after it is kicked off!
Can this plan be considered fair? In any case it is much better than the usual "breakdown into features" because it is closer to reality: it is a) easier to understand, b) refers to integration work and c) helps to see the point in time when it brings some value. However, it does not take into consideration user feedback.
Metaphor of four trees
13 years ago I was a professor assistant at a University. I was involved in scientific research work related to using artificial intelligence in expert systems. My supervisor helped me to build a research plan and introduced a rule of four trees.
Imagine a man walking down the road. There are four trees along the road. The man can see the first tree - its size, leaves, species - clearly. The second tree grows farther and is behind the first tree, so it is not that visible. The third tree is much farther than the second one, so the man can hardly see it, but he knows that there is a third tree. The fourth tree is impossible to see from where the man is located, so he does not even know that there is a fourth tree down the road.
The man is to walk past the trees one by one. Every time he passes by a tree, the next one becomes closer - hence more visible.
The supervisor told me to itemize the research plan starting from the first tree and move to next trees when they are more visible.
It is easy to see that the metaphor of four trees is applicable to ERP development. In this metaphor, trees refer to development cycles (iterations) while their visibility is closely related to the overall project scope which becomes clearer as feedback is received. In other words, user feedback is what makes trees visible.
Since there is only one tree completely visible at first, there is a sense in itemizing the first release - 'Contracts' in our example. Two weeks is an amount of time which is easy to break down into user stories and still keep the plan easy to read. The development camp may also specify what kind of feedback is expected after the first iteration to reveal the second tree.
As we have noted, my vision of estimation is closer to a plan or a roadmap rather than to a traditional estimate that has a table with numbers. Not only is the roadmap closer to reality, but it is also more informative. It contains a diverse information and allows the project owner to think of the ways to arrange the integration.
But let us talk about magic numbers that are often provided by technically minded developers. If you ask the development camp to provide "a ballpark estimate" - they will do that. But how is one to understand what they include in the estimates?
Usually, they rely on some principles. If they are agile software developers, their principles assume:
- Readiness of the staff of the company being automated.
- Exhaustiveness of provided information.
- Simplicity of the workflow and design.
Bear in mind that these principles exclude all external factors that may have influence on the estimates. This is why initial estimates are usually lower than the actual time. The developers do not include imperfection in the estimation. They do it for a reason.
Handling the estimation
From time to time, I encounter project owners that ask to include external factors in the estimates. They may get quite unhappy when estimates change as the project goes on and tell something like, 'I asked you to include all possible factors in the initial estimation and hoped that you would be professional enough to do that'.
Once we had a client who concluded all conversations with a phrase, 'If you have any questions, I am always here to answer them'. After every change in the estimation (which was part of a normal agile process) he complained, 'Why didn't you ask me about this before? I told you I was there to answer your questions'!
These examples show that some customers do not expect initial estimations to change. It usually happens when they have limitations either in budget or in time, so they want to know the timeline beforehand. They may consider the estimation unfair if it changes at a later stage of the project.
What I would like to explain is that an estimation based on the previously mentioned principles IS fair. On the contrary, an estimate that includes "all possible factors" or requires too many additional questions is not fair.
If we included some "possible factors" in the estimate, it would not be fair in our own eyes because such factors are out of our control. Having insufficient information, we would need to multiply our assessment by a certain "magic number" - but would it be fair?
If we asked too many questions, it would lead to spending much time on communication while a fair estimation should be done on the spot and refined only when it needs to be refined (at least this is what the agile approach says). Also, asking additional questions may have influence on the project owner's vision and even lead him to some doubts in abilities of the development camp.
A much more professional way to estimate a work scope is to do it immediately after a new information is received without thinking about anything that is out of discussion. What is not provided should not distract the developers just as if it did not exist.
In this section, I wanted to focus on how agile estimations are made and what they cover.
Development camps, since following the agile methods, use special rules and principles to provide predictable estimates. It is essential for software engineers to understand their clients, but professional clients need to understand their engineers too. So they may want to know these principles in order to have a better collaboration around estimates.
If a project owner transfers all responsibility for external factors, additional questions and similar things to the development camp, it may put the developers in a defensive position. They may start multiplying estimates by a certain coefficient and spend time on asking unnecessary questions. It is more productive when a project owner allows the development camp to focus on solving problems and learns how to handle their estimates.
There is a closely related subject I have introduced but not explained yet. It is a principle of simplicity which is essential to solve problems. This principle calls for a detailed explanation that I hope to provide in the next part.
I would like to talk about a core value of extreme programming which should also be a core value of software development in general. Let me begin with a story that can be a great example of what can happen to any workflow over time.
Once I was invited to explore a huge machine building plant. Their specialization was building heading machines, tunnel building machines and other mining equipment. Their end product was amazing, but everything was much worse in terms of inventory and production management.
There were many office blocks and big rooms with people in them. While exploring the enterprise workflows, I asked most employees about their responsibilities. Guess what the most frequent answer was?
"I take this book, go to this page, take numbers from this column and write them into this row in another book".
This is why enterprise employees are usually afraid of automation. They have reasons to think that they would have no job after the enterprise is automated. Or alternatively, they could be moved to real work that assumed more knowledge and responsibility.
Serve the servant
This is what happens to almost every business as it grows. It leads to a great management crisis. However, the head management continues to handle matters the same way they always did because changing administration procedures is costly.
So they spend more and more time instead of spending money to rearrange their offices.
I remember when I was taking driving tests, at the driver licensing office, I was told to go to the traffic police office and get a letter saying that I had never had a license before. I had to do it two weeks prior to the tests because it was how much time they would need to gather the information.
I always wondered why on earth I was part of this procedure? The driver licensing office and the traffic police office should have been integrated in the same system, they could share the same data, couldn't they? So, why did I have to spend my own time to visit a place I personally did not need anything from?
This way, an office that was created to serve my needs, turned into an entity I had to serve. This is exactly what is called bureaucracy - a necessity to serve an office that supposed to serve you.
In the business software world
The best examples of over-engineered business management software can be found in the US Healthcare world. At Anadea, we took part in development of 5 or 6 medical apps, and the medical market never failed to amaze me.
In 2010 CMS (Centers of Medicare and Medicaid) changed some old and obsolete standards. After that, the MDS 2.0 forms that had 200 fields turned into MDS 3.0 that had 800 fields and 200 rules to maintain consistency. They provided a script for calculating some metrics and updated this script over 10 times after it was published.
Recently we worked on some other standards called OASIS forms. They had about the same amount of fields and consistency rules. I have no idea why insurance companies require so many fields, except for the idea that they probably want to maintain their legacy databases and calculations.
The same is valid for the most well known software. When dealing with third party APIs of old and famous websites (including Salesforce, Bloomberg, etc.) it is easy to see that inflexibility. The reason why the owners do not change that is simple - they cannot.
So, this is what it takes to deal with heavy legacy. When you see a problem for the first time, the price of maintaining the current structures seems more affordable than the price of changing the system. But both costs grow over time and the business owners have to pay the price even if they do not make any decisions at all.
At the same time, if changes in a system were made as soon as they looked reasonable, the problem would be solved and price would be paid just once.
So, now we are about to understand the value of simplicity in software development.
The cost of change
Kent Beck in his "Extreme Programming" book explains that simplicity is what allows the developers to easily make changes in the project code at the late stage of its existence.
He provides two charts that compare the cost of change in a usual not-one-step-back development process and the cost of change in the agile development procedure. Here you can see these graphs on one chart:
See the difference? The cost of change in a usual development cycle grows over time because the developers are allowed to move only forward without thinking about bigger changes in the software architecture. The architecture should be built correctly from the very beginning, the usual approach says.
The agile (or extreme programming) approach assumes that the developers are allowed to simplify the code as soon as they see an opportunity to do it. This is why simplicity is one of the core values of software developers.
Is it really that simple?
And if it is, why the usual step-by-step approach does not borrow the same principle?
In general, yes, it is that simple. The core values define the coding style and eventually the result the project owner gets. However, it is not sufficient to be "agile" to reach the goal. Here is what should be taken into consideration as well:
The result depends on the experience of the development camp. Not only they should consider simplicity as a core value, but also know how to apply it in real projects.
Simplicity works only when combined with other values such as communication, feedback and courage. The main reason why the step-by-step approach does not integrate simplicity into its core is that the project owners are too much concerned about terms and milestones and are not brave enough to change the architecture.
Simplicity is only possible if the project owner shares the same values the development camp has. Otherwise the developers have to struggle to explain their reasons for simplifying the code, removing redundant or obsolete parts of it, etc.
As you can see, the step-by-step approach is built on a different basement. Non-agile software companies can develop amazing applications. However, I often see how companies that have about 1500 developers are unable to make changes in their software because of impersonal reasons.
The approach to ERP development, just like with medical and business management software, has to be flexible because these software solutions are supposed to live a long life. So, their code should be kept simple and maintainable as much as possible. As a project owner, you can reach this goal by having the same values your agile development camp has.
In particular, you may want to appreciate their efforts to achieve simplicity of the code.
Editor's note: originally published November 19, 2015; updated March 20, 2020.