Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 305 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
... and what if the business practice is wrong?
Shenpen
Member Posts: 386
What if the business practice is wrong?
I have made many posts that basically break down to a general complaint of "why do I have to rewrite half of Navision on every implementation"
where I ususally get the general answer that "In that case, you are doing something wrong."
In this topic, I would like to analyze it a bit deeper - investigating one specific wrong business practice in detail and would like
to invite everybody to come up with solutions to it.
CHAPTER I - the specific problem
Let's say you trade in cheap plastic pens - you know, the ones people give away as marketing gifts.
You import hundreds of thousands of them from China and generally sell a few hundred or a few thousand
on one sales order.
If the quantity of the inventory is high but the cost is low, you can generally expect go have wrong
inventory figures, often negative inventory etc. It is of course a wrong business practice, as inventory
generally should to be accurate, of course.
This is a business problem, how do you solve it with a business (not a technical) decision?
First, if you import pens in boxes of thousand, then you can make a rule that never open these boxes
but sell them intact, so you never accept an order that is not a multiple of 1000. And of course, if you basic
unit of inventory is a box of 1000, then you can easily make sure that is always accurate, right? So it is general
good business practice that you keep your inventory in units that are easy to account for, right? But it means you could
lose many of your customers so it's not an acceptable decision.
Then, you could do a break-bulk. You could receive your pens in boxes of 1000 and repackage it to boxes of
100, and then the box of 100 becomes the basic unit of inventory. You can even create some mixed boxes,
50 red pen and 50 blue pen for those customers who want more diversity and less quantity. A mixed box would
have a different Item No., and then you again have your inventory in units that are easy to account for,
so you can keep it accurate.
But it still does not work, for two reasons:
1) You don't only sell pens but literally thousands and thousands of different cheap Chinese plastic products. To break-bulk all of them
is simply not possible. I mean you are a small company with a headcount of 50.
2) You have some crazy customers who always order like 620 blue and 140 red pens and they would go to someone else
if you tell them that from now on it is not possible.
The reason is: why? If you are a small company, why do you need to have thousands of products? And why do you need to keep
the crazy customers who generate more problems than profits?
CHAPTER II - going deeper: investigating the general business model
I think the answer here is country- or region-specific. You know I had two projects in Western Europe (one in Denmark and one in Austria)
and both companies had very simple, very clean business processes - instead of trying to sell anything for anybody, they identify a clear need
on the market and focus vertically on that need. If the market needs pens, then I will sell pens and nothing else and they position themselves and a pen dealer.
Or, maybe they position themselves horizontally instead of vertically and say "we are a cheap products distributor, we will sell anything we can buy in a box of
1000 and sell in a box of 100", and optimize their whole business process for break-bulking everything, and they don't do any retail,
don't manufacture etc. So I think this problem does not exist in USA or Western Europe, because every company is focusing on a specific
vertical or horizontal market need, so they can optimize their procedures and make them easy, simple and clean. Actually, it is the only right
way to do efficient marketing, because the 101 of marketing is positioning, positioning, positioning - you got to differentiate yourself, no other way around, right?
By having simple, organized and opmitized procedures, you make the big leap from being a company to becoming an enterprise. Becoming an enterprise means
the process is more important than the people who work in the process: you don't need to rely on individual resourcefulness, but you have rules and policies for
everything and this makes everybody work like a small part in a big machine - should five of your key employees quit tomororrow, your enterprise would not collapse, as you can put
new recruits into their well-defined places in the enterprise machice.
Any of course WHEN you are an enterprise, you can implement an ERP.
I think this is general situation in Western Europe and USA.
Here in Hungary, or generally in Eastern Europe these things work differently. Say, some guy starts a company today to sell pens. He starts with five people - three sales, two warehouse guys.
He grows to a headcount of 10. Two sales do exports, one EU, one non-EU, two of them do inland sales, on of them managing key accounts and the other doing a kind
of mass distribution to smallers clients, and two clerks are working in a retail shop, there is an assistant and three guys in the warehouse. Then, he sees that there is a market gap in selling wine, so he hires two sales and a third warehouse guy and starts selling wine. Then, he sees that maybe it would
be cheaper if he bought wine in barrels and pour them into bottles in-house, so he again hires two folks who do the bottling of wine.
So, it is only a headcount of 15, and maybe a yearly sales of $2M, a really small company but look, but if add them together, eight different business processes with eight different group of requriements:
1) worldwide exports 2) EU exports 3) key account management 4) mass distribution 5) retail/POS 6) general warehouse 7) wine selling 8) wine bottling (from a software viewpoint, manufacturing).
Of course they still a bit small for a Navision implementation, but, let's say, in three years they start two other business streams, let's assume it means 4 new business processes, then they grow to a headcount
of 30 and yearly sales of $5M, they are likely target for a Navision salesman.
The first important thing to see is to see that this company is not an enterprise. It has no actual procedures. They just hired a guy who said he can sell wine and as long as he keeps his quota, it's okay.
They hired two other guys who said they can bottle wine and as long as no customer complains and and cost is acceptable, they just do it. No procedures, no rules. It means people are not replacable -
so they would be in a big problem if the two guys who bottle the wine leave.
How do they position themselves on the market, you can ask? If they do many things, how do they send a marketing message that they are different? The answer is they don't really do real
marketing. Yeah, they make some ads and print some mugs and t-shirts, but no real marketing strategy. The point is that they sell through the 1) personal contacts of salesmen 2) hard work of salesmen, meaning cold calls and whatever
3) low prices. There is only one rule: sell anything to anybody. Basically, it relies on personal talents and motivation: a bunch of clever and motivated salesmen are actually able to sell anything to anyone,
and a bunch of clever and motivated logistics, warehouse or engineering employees are able to live up to the promises of the salesmen and deliver on time,
because they rely on their individual talents, create clever ad-hoc solutions to problems, work overtime, ignore safety/security rules, which, while a big risk, can increase productivity, and pass over a significant percentage of the
problems to their vendors. So, more or less, it works. These companies are not rare - every company in Eastern Europe, who is not a vendor/subcontractor of a multinational corporation, or is not a big legacy enterprise from the socialist
era works this way.
why do people accept such working conditions? Because they have no other choice, only around 20-30% of the jobs are offered by multies or socialist-legacy big companies.
Besides, it more or less suits the Eastern European mindset. Remember when a Russian guy rewrite Norton Commander as Volkov Commander (and later FAR Manager)
and one lone guy could do much better work than a big American corporation? Eastern Europe has a kind of "lone hero" mindset, we often want to solve problems on our own, and we are much better at working than
at communicating. At least in a company I described above you can do your job without anybody bothering you by telling how you should do it as long as you have the results, and you don't have to communicate too much,
not too much meetings etc. In a multinational corporation or a socialist-legacy big company everything is about communication and formal and informal human networks, and not much actual work is taking place. Companies
described above suit our "lone hero" mentality better. I think this is the reason people accept it.
CHAPTER III - this company implementing an ERP
So, this company has now grew up, yearly sales of $5M, headcount of 30 and 12 different business procedures. No internal IT, this is important to note,
usually they have a young guy working part-time 4hrs a day troubleshooting PC-s and that's it. They have around 20 PC-s, with every user is basically a key user
as all of them does completely different things - it is best described as almost everybody being a separate department. They use, for example, an $8000 operations software for selling pen,
manage wine production and sales in Excel and Access, manage CRM in Access, have four different Excel spreadsheets with heavy macroing to manage other tasks, and have an external accountant.
Soon, the information system is becoming hard to manage - it is hard for the owner/manager to see figures on how things are going, and the flow of information is frequently blocked - the warehouse does
not know of a big sales order etc.
The owner/manager has it's mailbox stuffed with marketing material of ERP software - marketing material promising a clear overview, improved efficiency and
whatever else. This sounds cool, so they go for a demo. On the demo they see nice screens flying around with forms showing an impressive amount of fields,
they usually don't understand a word of the demonstration, but it is clear that they are seeing something truly powerful. If it is complicated, it must be cool, isn't it? Well...
Then they ask some questions. They ask that the things they have been doing in Excel with macros and whatever can now be done in the ERP. Usually, the answer is no - functionality in ERP
software (or at least Navision) can't compete with a well built, well-macroed Excel sheet. (The reason why is programming theory: ERP is based in imperative/procedural, or in some cases
OO programming, while Excel is based on functional programming - a SUM function is very similar to a LISP symbolic expression. Functional programming is generally superior at least for these tasks...
Although they don't know, peple using Excel in a proper way are actually doing a kind of lambda calculus.)
So what they get is four no answer and four offer to develop the requested functionality say five days each. Although if the customer would understand ERP or at least IT,
it should ring a bell that if you get four no out of four questions, then it means that later on they will ask another twenty questions and will get another twenty no answers...
but it does not happen. As for the implementor's side, you know one has to carefully balance honesty and making sales. You don't lie, you don't say a functionality exists
when it does not, but honestly tell it does not and offer development. But on the other hand, you don't remind your prospect that they will likely have another twenty questions
where the answer is also no, because, hey, you need to sell, so if they forgot to ask something, well, that's their problem. It's not very nice, but the other choice
is the collapse of your ERP business stream, as you only meet these kind of companies who are not real enterprises and therefore should not buy any ERP. And actually
if you really want to be honest and remind your prospect for these likely other twenty questions, well, it might be that the prospect takes it as an insult:
I know what I need, you don't have to tell me what should I ask.
So what happens then? The consultants have an uneasy feeling - there was no question about those functionalities that make this particular ERP strong:
no financial analysis (they have external accountant), no budgeting (they have no time for budgeting), only questions that are completely out of Navision
scope. It sounds like a hard project... but there is no other prospects, so let's make a proposal, licence, consulting, these four developments, whatever,
say, $100000. The prospect accepts it, and then you start the implementation.
CHAPTER IV - going back to the specific problem.
First you do you analysis phase. You are careful enough to ask how correct is the inventory - you still have nightmares of your first two project when you did not
know you have to ask it. You learned it by your "sweat and blood", because there is no damned book anywhere in the world that would tell you what questions to ask and
what traps to avoid when you implement an ERP. So now you ask it. You get the answer that the inventory is not correct, as pens have too high quantity and too low
cost to have it correct (no one will really count a shipment of 6590 PCS one by one), and the wine is fluid, so it evaporates, it is often spilled etc.
You talk to the owner/manager, he says he hopes this software will make business procedures more correct, f.e. both help and force people some way to keep a correct inventory.
This is, of course, a false dream, as no software ever can do such thing, because the reason inventory is incorrect is not that people are lazy, but they have to work too fast,
they don't have the necessary technical equipment, no organized procedure, headcount is way too low etc. In a situation like this, you cannot force or help people
work more correctly. Only thing the software can do - and ERP generally does it - is when the inventory is incorrect, make their lives even harder that it is.
You know half of Navision from costing to reservations can really behavely strangely if there is negative inventory. And you cannot ship an transfer order etc.
So you make the suggestions for business decisions I described above - break-bulk and whatever. For the above reasons, it gets rejected, you are being told "It is an amazingly
crazy idea to do things our customers don't want just in order to serve the software - you must implement it that way it serves us, not the other way around!"
You explain that the software is designed to serve right business practices, but it will also get rejected: "I am the one who decides what practice is best for us. And you truly mean
all these neat ideas developed in American universities would work in this business environment we have to operate in? You are suggesting me to wear tie and drink champange
while I am chopping a path in an equatorian jungle with cannibals and lion all around me. It's ridiculous. And you truly mean your $100000 software can't manage what our $8000 software could?
It means you sold me something that's bad. Bad for me, at least. Repair it instantly, or I will not pay anything, sue you etc."
This is the minute when you sigh and start hacking. Your other choice is to split ways with the customer - if you were clever enough not buy a licence then
you can split ways at least without any serious cost. But as all your customers fall into this category, you will do it two or three times and then it is likely that the vendor
of the software (Microsoft, in this case) will terminate your partnership as you obviously can't implement anything while others can. So, you start hacking instead.
You will find twenty or so similar problems and have no other way around but hacking.
Half a year later, you worked six months and have been paid only three months, the customer is not really content
as it is still below their original expectations but at least they have something they can work with, and they see the project was hard on you,
so they accept and pay it, you have a totally hacked implementation that is hard to support and impossible to upgrade, no one else can support it just you, so if you
quit there will be big trouble, you boss is not content as you worked 120 days but been paid only 60 days, and you yourself feel that you worked like a
machine gun on hacking Navision, you feel you did a very good job, you were dedicated, spent your nights and weekends hacking, and basically what you achieved
was to turn a disastrous situation into a somewhat disappointing one. No feeling of success. And the worst thing is that nobody knows what amazing job you did, because nobody - nor the customer
nor your salesmen nor your boss - wants to admit this client should have not implemented an ERP. But as all clients are this kind, the final answer is that you should
not sell ERP in Eastern Europe. But on the other hand, you WANT to work with ERP, as this is a job where one can really, really learn - one learns how to manufacture
radios on one project, learns how to sell clothes on the other project etc. an ERP consultant will have more experience on how to manage businesses in ten years than
a managing director has in thirty years. ERP turns people into real business King Kongs. If you start a company after ten years of ERP experience,
and will, say, manufacture socks, you can be sure that you will be really, really successful. So you don't want to stop working with ERP.
I have made many posts that basically break down to a general complaint of "why do I have to rewrite half of Navision on every implementation"
where I ususally get the general answer that "In that case, you are doing something wrong."
In this topic, I would like to analyze it a bit deeper - investigating one specific wrong business practice in detail and would like
to invite everybody to come up with solutions to it.
CHAPTER I - the specific problem
Let's say you trade in cheap plastic pens - you know, the ones people give away as marketing gifts.
You import hundreds of thousands of them from China and generally sell a few hundred or a few thousand
on one sales order.
If the quantity of the inventory is high but the cost is low, you can generally expect go have wrong
inventory figures, often negative inventory etc. It is of course a wrong business practice, as inventory
generally should to be accurate, of course.
This is a business problem, how do you solve it with a business (not a technical) decision?
First, if you import pens in boxes of thousand, then you can make a rule that never open these boxes
but sell them intact, so you never accept an order that is not a multiple of 1000. And of course, if you basic
unit of inventory is a box of 1000, then you can easily make sure that is always accurate, right? So it is general
good business practice that you keep your inventory in units that are easy to account for, right? But it means you could
lose many of your customers so it's not an acceptable decision.
Then, you could do a break-bulk. You could receive your pens in boxes of 1000 and repackage it to boxes of
100, and then the box of 100 becomes the basic unit of inventory. You can even create some mixed boxes,
50 red pen and 50 blue pen for those customers who want more diversity and less quantity. A mixed box would
have a different Item No., and then you again have your inventory in units that are easy to account for,
so you can keep it accurate.
But it still does not work, for two reasons:
1) You don't only sell pens but literally thousands and thousands of different cheap Chinese plastic products. To break-bulk all of them
is simply not possible. I mean you are a small company with a headcount of 50.
2) You have some crazy customers who always order like 620 blue and 140 red pens and they would go to someone else
if you tell them that from now on it is not possible.
The reason is: why? If you are a small company, why do you need to have thousands of products? And why do you need to keep
the crazy customers who generate more problems than profits?
CHAPTER II - going deeper: investigating the general business model
I think the answer here is country- or region-specific. You know I had two projects in Western Europe (one in Denmark and one in Austria)
and both companies had very simple, very clean business processes - instead of trying to sell anything for anybody, they identify a clear need
on the market and focus vertically on that need. If the market needs pens, then I will sell pens and nothing else and they position themselves and a pen dealer.
Or, maybe they position themselves horizontally instead of vertically and say "we are a cheap products distributor, we will sell anything we can buy in a box of
1000 and sell in a box of 100", and optimize their whole business process for break-bulking everything, and they don't do any retail,
don't manufacture etc. So I think this problem does not exist in USA or Western Europe, because every company is focusing on a specific
vertical or horizontal market need, so they can optimize their procedures and make them easy, simple and clean. Actually, it is the only right
way to do efficient marketing, because the 101 of marketing is positioning, positioning, positioning - you got to differentiate yourself, no other way around, right?
By having simple, organized and opmitized procedures, you make the big leap from being a company to becoming an enterprise. Becoming an enterprise means
the process is more important than the people who work in the process: you don't need to rely on individual resourcefulness, but you have rules and policies for
everything and this makes everybody work like a small part in a big machine - should five of your key employees quit tomororrow, your enterprise would not collapse, as you can put
new recruits into their well-defined places in the enterprise machice.
Any of course WHEN you are an enterprise, you can implement an ERP.
I think this is general situation in Western Europe and USA.
Here in Hungary, or generally in Eastern Europe these things work differently. Say, some guy starts a company today to sell pens. He starts with five people - three sales, two warehouse guys.
He grows to a headcount of 10. Two sales do exports, one EU, one non-EU, two of them do inland sales, on of them managing key accounts and the other doing a kind
of mass distribution to smallers clients, and two clerks are working in a retail shop, there is an assistant and three guys in the warehouse. Then, he sees that there is a market gap in selling wine, so he hires two sales and a third warehouse guy and starts selling wine. Then, he sees that maybe it would
be cheaper if he bought wine in barrels and pour them into bottles in-house, so he again hires two folks who do the bottling of wine.
So, it is only a headcount of 15, and maybe a yearly sales of $2M, a really small company but look, but if add them together, eight different business processes with eight different group of requriements:
1) worldwide exports 2) EU exports 3) key account management 4) mass distribution 5) retail/POS 6) general warehouse 7) wine selling 8) wine bottling (from a software viewpoint, manufacturing).
Of course they still a bit small for a Navision implementation, but, let's say, in three years they start two other business streams, let's assume it means 4 new business processes, then they grow to a headcount
of 30 and yearly sales of $5M, they are likely target for a Navision salesman.
The first important thing to see is to see that this company is not an enterprise. It has no actual procedures. They just hired a guy who said he can sell wine and as long as he keeps his quota, it's okay.
They hired two other guys who said they can bottle wine and as long as no customer complains and and cost is acceptable, they just do it. No procedures, no rules. It means people are not replacable -
so they would be in a big problem if the two guys who bottle the wine leave.
How do they position themselves on the market, you can ask? If they do many things, how do they send a marketing message that they are different? The answer is they don't really do real
marketing. Yeah, they make some ads and print some mugs and t-shirts, but no real marketing strategy. The point is that they sell through the 1) personal contacts of salesmen 2) hard work of salesmen, meaning cold calls and whatever
3) low prices. There is only one rule: sell anything to anybody. Basically, it relies on personal talents and motivation: a bunch of clever and motivated salesmen are actually able to sell anything to anyone,
and a bunch of clever and motivated logistics, warehouse or engineering employees are able to live up to the promises of the salesmen and deliver on time,
because they rely on their individual talents, create clever ad-hoc solutions to problems, work overtime, ignore safety/security rules, which, while a big risk, can increase productivity, and pass over a significant percentage of the
problems to their vendors. So, more or less, it works. These companies are not rare - every company in Eastern Europe, who is not a vendor/subcontractor of a multinational corporation, or is not a big legacy enterprise from the socialist
era works this way.
why do people accept such working conditions? Because they have no other choice, only around 20-30% of the jobs are offered by multies or socialist-legacy big companies.
Besides, it more or less suits the Eastern European mindset. Remember when a Russian guy rewrite Norton Commander as Volkov Commander (and later FAR Manager)
and one lone guy could do much better work than a big American corporation? Eastern Europe has a kind of "lone hero" mindset, we often want to solve problems on our own, and we are much better at working than
at communicating. At least in a company I described above you can do your job without anybody bothering you by telling how you should do it as long as you have the results, and you don't have to communicate too much,
not too much meetings etc. In a multinational corporation or a socialist-legacy big company everything is about communication and formal and informal human networks, and not much actual work is taking place. Companies
described above suit our "lone hero" mentality better. I think this is the reason people accept it.
CHAPTER III - this company implementing an ERP
So, this company has now grew up, yearly sales of $5M, headcount of 30 and 12 different business procedures. No internal IT, this is important to note,
usually they have a young guy working part-time 4hrs a day troubleshooting PC-s and that's it. They have around 20 PC-s, with every user is basically a key user
as all of them does completely different things - it is best described as almost everybody being a separate department. They use, for example, an $8000 operations software for selling pen,
manage wine production and sales in Excel and Access, manage CRM in Access, have four different Excel spreadsheets with heavy macroing to manage other tasks, and have an external accountant.
Soon, the information system is becoming hard to manage - it is hard for the owner/manager to see figures on how things are going, and the flow of information is frequently blocked - the warehouse does
not know of a big sales order etc.
The owner/manager has it's mailbox stuffed with marketing material of ERP software - marketing material promising a clear overview, improved efficiency and
whatever else. This sounds cool, so they go for a demo. On the demo they see nice screens flying around with forms showing an impressive amount of fields,
they usually don't understand a word of the demonstration, but it is clear that they are seeing something truly powerful. If it is complicated, it must be cool, isn't it? Well...
Then they ask some questions. They ask that the things they have been doing in Excel with macros and whatever can now be done in the ERP. Usually, the answer is no - functionality in ERP
software (or at least Navision) can't compete with a well built, well-macroed Excel sheet. (The reason why is programming theory: ERP is based in imperative/procedural, or in some cases
OO programming, while Excel is based on functional programming - a SUM function is very similar to a LISP symbolic expression. Functional programming is generally superior at least for these tasks...
Although they don't know, peple using Excel in a proper way are actually doing a kind of lambda calculus.)
So what they get is four no answer and four offer to develop the requested functionality say five days each. Although if the customer would understand ERP or at least IT,
it should ring a bell that if you get four no out of four questions, then it means that later on they will ask another twenty questions and will get another twenty no answers...
but it does not happen. As for the implementor's side, you know one has to carefully balance honesty and making sales. You don't lie, you don't say a functionality exists
when it does not, but honestly tell it does not and offer development. But on the other hand, you don't remind your prospect that they will likely have another twenty questions
where the answer is also no, because, hey, you need to sell, so if they forgot to ask something, well, that's their problem. It's not very nice, but the other choice
is the collapse of your ERP business stream, as you only meet these kind of companies who are not real enterprises and therefore should not buy any ERP. And actually
if you really want to be honest and remind your prospect for these likely other twenty questions, well, it might be that the prospect takes it as an insult:
I know what I need, you don't have to tell me what should I ask.
So what happens then? The consultants have an uneasy feeling - there was no question about those functionalities that make this particular ERP strong:
no financial analysis (they have external accountant), no budgeting (they have no time for budgeting), only questions that are completely out of Navision
scope. It sounds like a hard project... but there is no other prospects, so let's make a proposal, licence, consulting, these four developments, whatever,
say, $100000. The prospect accepts it, and then you start the implementation.
CHAPTER IV - going back to the specific problem.
First you do you analysis phase. You are careful enough to ask how correct is the inventory - you still have nightmares of your first two project when you did not
know you have to ask it. You learned it by your "sweat and blood", because there is no damned book anywhere in the world that would tell you what questions to ask and
what traps to avoid when you implement an ERP. So now you ask it. You get the answer that the inventory is not correct, as pens have too high quantity and too low
cost to have it correct (no one will really count a shipment of 6590 PCS one by one), and the wine is fluid, so it evaporates, it is often spilled etc.
You talk to the owner/manager, he says he hopes this software will make business procedures more correct, f.e. both help and force people some way to keep a correct inventory.
This is, of course, a false dream, as no software ever can do such thing, because the reason inventory is incorrect is not that people are lazy, but they have to work too fast,
they don't have the necessary technical equipment, no organized procedure, headcount is way too low etc. In a situation like this, you cannot force or help people
work more correctly. Only thing the software can do - and ERP generally does it - is when the inventory is incorrect, make their lives even harder that it is.
You know half of Navision from costing to reservations can really behavely strangely if there is negative inventory. And you cannot ship an transfer order etc.
So you make the suggestions for business decisions I described above - break-bulk and whatever. For the above reasons, it gets rejected, you are being told "It is an amazingly
crazy idea to do things our customers don't want just in order to serve the software - you must implement it that way it serves us, not the other way around!"
You explain that the software is designed to serve right business practices, but it will also get rejected: "I am the one who decides what practice is best for us. And you truly mean
all these neat ideas developed in American universities would work in this business environment we have to operate in? You are suggesting me to wear tie and drink champange
while I am chopping a path in an equatorian jungle with cannibals and lion all around me. It's ridiculous. And you truly mean your $100000 software can't manage what our $8000 software could?
It means you sold me something that's bad. Bad for me, at least. Repair it instantly, or I will not pay anything, sue you etc."
This is the minute when you sigh and start hacking. Your other choice is to split ways with the customer - if you were clever enough not buy a licence then
you can split ways at least without any serious cost. But as all your customers fall into this category, you will do it two or three times and then it is likely that the vendor
of the software (Microsoft, in this case) will terminate your partnership as you obviously can't implement anything while others can. So, you start hacking instead.
You will find twenty or so similar problems and have no other way around but hacking.
Half a year later, you worked six months and have been paid only three months, the customer is not really content
as it is still below their original expectations but at least they have something they can work with, and they see the project was hard on you,
so they accept and pay it, you have a totally hacked implementation that is hard to support and impossible to upgrade, no one else can support it just you, so if you
quit there will be big trouble, you boss is not content as you worked 120 days but been paid only 60 days, and you yourself feel that you worked like a
machine gun on hacking Navision, you feel you did a very good job, you were dedicated, spent your nights and weekends hacking, and basically what you achieved
was to turn a disastrous situation into a somewhat disappointing one. No feeling of success. And the worst thing is that nobody knows what amazing job you did, because nobody - nor the customer
nor your salesmen nor your boss - wants to admit this client should have not implemented an ERP. But as all clients are this kind, the final answer is that you should
not sell ERP in Eastern Europe. But on the other hand, you WANT to work with ERP, as this is a job where one can really, really learn - one learns how to manufacture
radios on one project, learns how to sell clothes on the other project etc. an ERP consultant will have more experience on how to manage businesses in ten years than
a managing director has in thirty years. ERP turns people into real business King Kongs. If you start a company after ten years of ERP experience,
and will, say, manufacture socks, you can be sure that you will be really, really successful. So you don't want to stop working with ERP.
Do It Yourself is they key. Standard code might work - your code surely works.
0
Comments
Have a look at www.go-live.us
Do It Yourself is they key. Standard code might work - your code surely works.
Seems by looking at the imaginary company there, www.cronuswidgets.com, that it does not fit into what I described. It has basically one business stream, one business procedure, but are big - 120.000 sales means big. Operating wordwide means big. They are big and simple. The companies I describe here are small and complicated as hell. Hell, Cronus Widgets does have a mission statement and it in itself means they are completely different than these companies I describe here - their only mission is "sell anything we can make money of".
Do It Yourself is they key. Standard code might work - your code surely works.
RIS Plus, LLC
Do It Yourself is they key. Standard code might work - your code surely works.
http://www.BiloBeauty.com
http://www.autismspeaks.org
RIS Plus, LLC
Do It Yourself is they key. Standard code might work - your code surely works.
But at least I found some better, more accurate words to describe the problem: Western companies are generally vertical, they pick one segment of the market and then go deep - they always want to be a "leading global supplier of" something.
Eastern European companies are horizontal - started out as one tiny vertical company and adding more and more kinds of products and services hiring 1 or 2 folks to do each.
If you are a vertical company, it means you don't have many kinds of activities, but those ones you have you have and want to do well, really well - you have 10 or 30 or whatever people in one department, doing exactly the same kind of thing, so it is both easy to implement a solution to both thelp and control their work and it is also necessary, because it can really add great value.
Navision is, essentially a horizontal solution - it does (almost) everything but only on a superficial, "barely enough" level. But it is not a problem for you as you don't have many kind of activities, so you can choose those few features that apply to your few kinds of activites and then either enchance them with a couple of dozens of days of development or just buy a vertical add-on where it has already been done.
But if you are a horizontal company, having dozens of activities but only one or two employees for each, then if you buy Navision, then first, you need a big expensive licence, second, you discover that the features are superficial, all of them are only barely enable you to do your work but do not really help your work. The point is that one-man departments don't have less requirements than 10-men departments, basically, they have more, because they are much more overburdened as they can't distribute work between each other, so they need as much help from the software as possible.
And then basically you need dozens of vertical solutions for your dozens of activities.
And it can break down to only these three options:
1) If you have a binding contract then can do nothing else but write off the investment and try to live with it
2) Or you can shell out a lot of money for hundreds of small customizations that are basically take the form of a dozen of small vertical solutions
3) Or if you were lucky, and your consultants were lacking projects and were willing to sign fixed-priced contracts, you can simply force them to make these for free. However, "slave labour"
So what can you do as a client? Hire a Navision programmer or two, forget updates and wait a year or too. Sooner or later you will have these dozens of vertical systems.
And what can you do as a consultant? Not much. Either change your profession or the country you live in. Netherlands just sounds better and better to me
Do It Yourself is they key. Standard code might work - your code surely works.
It is our job as consultants to determine how well the software and the potential customer fit together, and estimate what it takes to make the solution work. There are always surprises of course, it is impossible to determine this 100%, but if you go in thinking it is a perfect fit and it turns out to be the opposite, then the presales job was not done very well.
What happens a lot is that people get very excited about the idea that they're going to have a 'supersystem' without any effort, and they are very disappointed when they discover that it is actually a LOT of work making an ERP system happen.
RIS Plus, LLC
The basic problem is that one's employer is not paying for telling people they should not buy our product... So some kind of compromise must be made between honesty and sales. My version of compromise is being open about direct requirements vs. direct functionalities, but don't touch conceptual issues, because I can explain to my bosses and salesmen that "they wanted X,Y,Z but we have N,P,K" but I can't explain things like "see, they're just a pumped-up shop, not an enterprise, should not sell them enterprise applications" because the I would be told "That's their problem.", which is of course no true, because it will be me, not them, who will need to do these overnight customization runs.
What to say? Maybe what wrote earlier - either change the profession, or change the country. Any better idea?
Do It Yourself is they key. Standard code might work - your code surely works.
We are a small Business, we do about USD$1.5M a year, and I have some technical background. The whole point for us buying Navision is to help us streamline operations, and to get complex features that regular accounting system do not have, e.g. demand forecast. I know that I may be out of my league looking into Navision!!!
I can tell you from experience that salespeople will sell their mothers if they can! and I think it is very irresponsible for a company to sell a solution to a customer knowing that they will not have a successful implementation. for the example that you gave, the salesperson should have told them that they are not ready of an ERP. Some companies have serious internal problems, or have ad-hoc processes, and think that an ERP will help them fix things. Locally I know of 3 companies that were not ready for an ERP, and the results were a disaster.
In our case we gave a list of "Must Have" features to a company that sells Navision & a company that sells SAP Business One. The Navision provider was a lot more forthcoming about what features we can actually get, and the costs involved. and they the flat out told us that if we want feature #3, it will cost X amount of dollars to get it.
The Navision provider's recommendation is that we divide the project over 2 years, and by the end of the 2nd year we will have ALL the features that we want. And that is what we are going to do.
Small companies have very little margin of error, when it comes high ticket expenditures..... so a solution provider can do a lot of damage if they promise something that they cannot deliver.
regards
And the problem is that when I tell clients 3-months-for-everything is possible, a rural entrepreneur will pop-up from a redneck village with two 19-years old programmers and promise to deliver everything in 2 months for 30 days of consulting cost. Of course they will fall, but still win the project from me. The problem is that MS cannot reject partner applications, they have to accept everybody. No quality filtering. I wish it would be more rigorous or at least the clients would be clever enough to ask for certifications, references not just looking at the price tag and the shiny promise of features.
Suggestion: I suggest you to internalize as much of the work as you can (writing reports, end-user training etc.)
Do It Yourself is they key. Standard code might work - your code surely works.
as for your situation ...... you are in a tight spot, but sometimes your better off not selling!!! I am in no position to give recommendations, but why don't you look into smaller apps for these kinds of situations?!?!
thank you for the advise
I was following the developement of this thread, since it is very relevant to me. I think hsmex has some very clear and consise input to your issue. It is not an "Eastern European" issue, it is an issue with the methodolgy in which a company sells its solution.
It is critical that a client clearly and properly evaluates the NSC that they will buy from. Its no use to just go with the biggest, or go with the cheapest, there is much more than just that. If you have a solid methodology, then you shoudl in no way fear the 19yo farmers, they just can not complete.
Navision it self can not be a successful Vertical product. What it can be though is a very solid horzontal platform that an ISV can use as the basis of a very solid and potentially sucessful Vertical product. But a Vertical solution is not about code, it is about an ISV that knows the industry, and knows its clients.
If the market is for Horizontal solutions, then it is necessary to know that market, and sell to the right client. For e a compay with 8 business units, and $2mill revenue is not a Navision customer. Instead they should be just looking at Excel.
I must say that delivering Navision in Hungary was a very interesting experience, definitely uniquely differnt from any other Eastern European county that I implemented in for sure. But still you can make it happen, just find the right clients, and make sure that you are the right NSC for them. And if you find it necessary to blame the product, then you really should not be selling it.
Amen; :oops:
Generally I agree with you, what I am starting to undestand that my problem is basically a sales problem: if a project is sold in the bad way then I can hack 14 hours a day all the way long and still have an angry customer.
I think the key is to find the right customer for the product (the product, in this sense, is rather a good vertical add-on than plain Navi). So it's a product -> customer way of "push" kind of sales than can sell a project in a way that it will be really feasible and without unacceptable levels of stress and anger. What we always did was quite the opposite, a customer -> product kind of "pull" sales, where the salespeople found someone who was interested in something remotely resembling an ERP and then selling them XXX days of Navi development. And other solution centers here mostly do the same. The reason? The general "sell everything" approach of greedy salespeople and company owners. But as clients also work the "sell everything" way, they also don't really have established, widely accepted business practices that could serve as a basis for an add-on. However, I think in the very long run this add-on based approach will work, because I think that it must be some way possible to find some least common denominator of the way people do business here and build add-ons upon it, but it needs at least a minimum of five years and now I am too tired of this mess to endure it for that long.
So I think I will move to Western Europe somewhere around August, find a company that specializes in add-ons I have the most experience in (manufacturing/warehouse/logistics), and live a mostly calm life with clearly defined scopes, goals, and tasks instead of "go guys and do something we can charge for". Or at least I hope so.
As for other topics you mentioned, I find that funny to mention Excel as an alternative to Navi for smaller clients, as here we have at least 50 different Clipper/FoxPro-based accounting/operations software costing about EUR 5000 for ten users and while they are generally slow and lack in reporting/analysis, they manage day-to-day operations really quite well, I mean two clicks and all the complicated duty and tax forms come rolling out of the printer etc. This is one of the reason of our problems - users expect Navi to ten times better as it is ten times as expensive, while it actually aims towards a totally different direction than these software.
As for blaming the product, well, as I said we don't really have an add-on culture here, for reasons I mentioned and other reason is that simply Navi is expensive enough out of the box. I honestly thought before I started working with it, that it is something "finished" for such a price. None of our business plans considered selling just a framework for tens of thousands euroes of licence cost. Of course, for a development framework it is really good, I agree. I think this is country-specific. If in Western Europe one pays 60 000 EUR in a year to a good programmer, then Navision licence is not expensive compared to it and then one can consider it as a development framework. (I even think that a good add-on could even save on the licence costs - replacing expensive manufacturing/WMS granules with ones on their own.)
As for the methodologies, well, the official ones generally consist of writing a ton of papers, and whenever I tried to follow them what I generally got was that customers were angry for wasting expensive consultant days on writing stuff they won't ever read, instead of creating solutions. However, I agree methodologies can be useful, but only if they consist of nothing but crystallized hands-on industrial experience. After a few research-like projects in a given industry, one can create document templates and so on, I agree, but I would avoid the too heavyweight and too general "official" methodologies.
Do It Yourself is they key. Standard code might work - your code surely works.