A general answer to some of the questions here

Miklos_Hollender

Recently, some questions arised here in MiBuSo that show inexperience in ERP systems in general, not only in Navision. Of course it's understandable, but I think if you are a startup solution center, for gosh's sake, HIRE someone who already implemented another ERP system before! (And not only G/L and Finances, but operations as well: sales, purchase, inventory, warehouse and manufacturing). It will be EXTREMELY hard to implement Navision without somebody who has previous ERP experience.

ERP systems are very similar to each other. If you have somebody on the team who implemented another EPR before, then you at least know how it SHOULD work, what it SHOULD do, what are the typical features, what are the typical limitations of ERP systems - f.e. many ERP systems support assembly manufacturing but not process production - , what are the typical problems and typical solutions, what are the typical bugs - f.e. MANY ERP systems have serious inventory costing issues - and so on. In this case, your team will know WHAT to do and will only have to find out HOW to do it in Navision, which is a lot easier. Having to learn both WHAT and HOW on your first ERP project is a clear way to disaster.

For example, from some of the questions arised here in the forum, if you had somebody who has previous experience with another ERP system would know that

- don't even try to implement process production capacity planning with a system that uses the term Machine Center, because that's strictly an assembly manufacturing term

- the general practice for ANY ERP system to handle completely outsourced manufacturing is to transfer material out, consume, output, transfer products back

- that vendor consignments in ANY ERP system are usually handled by marking the PO as arrived but NOT receiving it

- that you have to do quality control on goods received BEFORE you receive goods in ANY ERP system, because receiving in an ERP term means ACCEPTING the goods, not just noting that they arrived

and so on, and so on. If you feel you are in these shoes I described here, HIRE somebody who implemented a lot of Scala or Exact or Baan something like that before, and not only Finances, but operations as well, or you will face a really, really hard time.

johnson_alonso

Dear Miklos,
You have sent a topic but in a wrong forum. Pls read before posting. I think your topic should actually be posted in the general chat forum. All forum members also always visit the forum. don't worry. But it depends on moderator.



Rgds,
Johnson

"hey you, slaves go hang your owner, draw your name among their ashes"

Administrator

[Topic moved from Navision to General Chat forum]

bbrown

I have been in this business since the late 1980's and during that time have worked with several different systems. I wish I had a resource like MIBUSO in my early days.

I agree that knowing another system can help you with the learning curve of Navision. Much like in computer networks, if you know Novell Netware it will probably help you to figure out Microsoft Networking. But you need to learn that first system, and for some people that will be Navision.

that vendor consignments in ANY ERP system are usually handled by marking the PO as arrived but NOT receiving it

How do you keep track of what has been received and sold? Do you just trust the vendor (bad idea). You should receive the inventory in a manner in which it can be isolated from the rest of the inventory. This way you have a way to reconcile with the vendor's invoices.

that you have to do quality control on goods received BEFORE you receive goods in ANY ERP system, because receiving in an ERP term means ACCEPTING the goods, not just noting that they arrived

This can depend on the FOB terms. Many vendors ship FOB their dock. You own the inventory tht is on the truck, so why not receive it. Also I have never met a truck driver that is willing to sit around while you test things.

Miklos_Hollender

BlackTiger,

To successfully implement any ERP system you don't need big experience in "other" systems. You need only 2 basic things:
1) ability to understand customer's business;
2) perfect knowledge of your ERP system

Please think it over again. First, customers don't speak of business processes that they think trivial, standard and "everybody does this this way". Second, a typical 10-15 days analysis phase does not provide enough time to describe any trivial business process in a detailed way. Third, one can swiftly lose respect at a customer, if one needs to be explained trivial business procedures. Fourth, if you know how typical processes are modeled in any other ERP system, if you know the general concepts, then it is a lot easier to figure out how it works in Navision, because you know what to look for.

Let's have an example. Let's say you got a customer who says "I sell goods in consignment: I ship them to resellers, but I don't invoice it, I invoice only invoice their consumption they report me monthly. Can your system handle it?" Then the customer stops and waits for an answer.

Now, if you are new to Navision and new to ERP systems as well, then you will start scratching your head, or start brainstorming, start coming up a with a lot of ideas. Both are sure ways to lose respect.

However, if you have someone on your team, who has experience implementing another ERP systems, he will say: "Sure, the general solution is to have a locations/warehouse representing each reseller. Goods need to be shipped there by the features offered by the system for inter-warehouse inventory movements. We will need to check whether Navision has such a function - preferably one that is also able to print a decent Shipment Note. Then each month you need to decrease the inventory and invoice it - we have to check whether Navision is able to automatically decrease inventory at invoicing. I think we should develop a way to import these consumption reports from Excel, you don't want to key them in, right?" And in this case, you know what to check, what to look for in Navision, then only thing you need to figure out is just how to do them. It is a lot easier this way. Or, put in other words, it's almost impossible without this general ERP/operations knowledge.

Please think this over. There ARE standard procedures and standard ways on how to implement them in any system. I know how hard it can be without previous ERP knowledge, because I had none when I started working with Navision in 2002 - I remember, I didn't even know what a Sales Quote is, I thought it' s a sales quota - and my coworkers only knew ERP from a financial, but not from an operations perspective - it was really a hard time for me, all I now know I had to learn by "blood, sweat and tears" (Churchill). Our lack of general ERP/operations knowledge meant that in 2002 our HQ inquired us what's happening for having 170% utilization (14 hrs/day) in my timesheet for months and months - this hard it is without general ERP/operations knowledge.

So having someone with a clue about general ERP practices and typical problems is indispensable.

Alex_Chow

To have a good implementation, you almost need someone who has:
1. Good knowledge of Navision
-AND-
2. Good knowledge of business practices

If these 2 skills belongs to 2 different people, although you can still have a good implementation, won't be as smooth as if you have a person that has the 2 skills together.

Miklos_Hollender

If implementor has no experience in ERP systems at all - project will be dead.

If implementor has no experience in Navision - project will be dead as well.

I, have to disagree again. There is no such thing as dead project, only a project that has been given up.

We started in 2002 with the worst possible situation: it's been Navi 3.6, the most buggy release in the last 10 years, almost nonexistent localization, a clever, but newbie guy as local MS support and for international support only that useless Service System where the only answer had been "fixed in next version", we had no external help, had zero Navi experience, we had two consultants who had been experienced only in the financial part of other ERP systems, had me as an operations consultant (warehouse etc.) right out of business school with almost zero work experienced (OK I have designed a Health, Safety, Environment system before, but that was really different of course), nobody had any experience in business logic programming let alone C/AL, and so on.

Results?

The client is still using Navision and is still supported by one of the old team, although in different company colors. How did we pull that off? By sheer dedication. We worked 14 hours per day for months, worked 400 days as opposed to the proposed 60 days, and I lost 20 pounds of weight just out of stress, but we did not give up, simply because we could not - it was the first client after 9 months of holding sales demos and generating zero revenue - had we given up, when would have started making revenue?

There is no such thing as an impossible project.

However, there are huge differences in difficulty. Of course you are right that having someone with Navision experience is preferred, but this topic is for those guys who are in a country where it is almost impossible (India for example) and ask some really strange questions in the forum. My point is that having someone with previous experience of implementing the operations part of any other ERP system can reduce the trouble by 50%, previous Navision experience can reduce trouble by a further 30%, so even when the second is impossible, the first one in itself a really huge step forward.

I have two new consultants with previous ERP experience (one of them Baan, the other one a local system) and I am completely amazed how fast they are picking up Navisoon - because they know what to look for.

Miklos_Hollender

"How much possible customers you have lost because you was busy 400 days instead of 60. "

How much? None. Sales were quite active during that time, and the only thing we lost was we started the next project a month later than expected, which was not too much.

"Dead project" - is when you got paid nothing at all. While you can pay a month's salary to a consultant for three days rate here, it's rare to deem projects as dead.

Is sales going so well in your original homeland? I mean we both have similar history, we both got free when Kissinger managed to wrestle Gorbachev into giving up the empire... so your economy theoretically shouldn't be so different from ours. We have 30 MSB partners who have a total of 60 sales per year, with one "gorilla" - just like in the old OnTarget Sales Methodology - selling 30/year so if you get 2/year, you are quite lucky.


If anybody is curious, yes, I am Shenpen, as you have probably figured, I just decided to

1) use my real name, because it's more mature this way
2) try to complain less and be more constructive, and it's easier with a new nick.

And, once again, this topic is not about the UK, not about Latvia and not about Hungary, where the situation is slowly starting to become normal. This project is for helping all those poor guys in Asia, especially in India, who - by their questions on the Navision forum - seem to have impossible missions put on their backs. They are in even worse conditions than we have been. I really want to help them. It's not about you or me playing clever and throwing some nice wisdoms here from our now comfortable positions - these guys suffer, they really do, and therefore I have to help, and would encourage you to do so. It's an ethical question. Of course you are doing it on this forum, in a technical way, but we should also help them in a conceptual way as well. Telling them a project is dead if you don't have a Navision expert won't help them much.

Miklos_Hollender

ACCPAC - by this name, didn't it have the same problem as with Navision: a too accounting, too financial way of thinking (as opposed to operations), and concentrating less to those user who contribute more to business productivity: salespeople, warehouse people, manufacturing team leaders etc. ? For example, could it by default or by a small customization, warn a salesman that a customer of his will soon have a birthday? Or print a bar code for all those products that have sales price changed in the last week? If not, then it might have been not much help in Navision projects.

Miklos_Hollender

Very impressive. Actually, I'd disagree with that also - MS introduced a lot of crappy new functionality, but at least repaired old ones that were bad or nonexistent for a long time, like BOM Journal's cost adjustment - but, once again, this topic is not about you, not about me. We are doing just fine now, I think. (Especially that I'm also gonna move to the UK in August.)

Once again, what I would like to do is to help those poor Asian guys, who seem to have no clue about ERP in general and, by their questions on the forum, seem to have impossible missions put on their backs. If I had 14hrs for a three months, they look like they will have 20hrs for a half a year, which is impossible, it mean they will have to give up, which might mean a big psychological scar. It's not just business, as long as one is younger than 30. Do you want to join me for helping them in conceptual ways or not?

ara3n

Is it normal to to commit suicide or kill somebody or go to the mountains forever just for some code?

I don't think so. :roll:

Alex_Chow

ara3n wrote:

Is it normal to to commit suicide or kill somebody or go to the mountains forever just for some code?

I don't think so. :roll:

Normality is relative. 8)

Alex_Chow

Miklos Hollender wrote:

Once again, what I would like to do is to help those poor Asian guys, who seem to have no clue about ERP in general and, by their questions on the forum, seem to have impossible missions put on their backs. If I had 14hrs for a three months, they look like they will have 20hrs for a half a year, which is impossible, it mean they will have to give up, which might mean a big psychological scar. It's not just business, as long as one is younger than 30. Do you want to join me for helping them in conceptual ways or not?

Careful my friend. Remember that once, you were a n00b too.

ara3n

But it's a lot easier to fix the stupid mistakes and at the end you are the hero to the client. With complex problems you spend hours and hours.

Miklos_Hollender

"But it's a lot easier to fix the stupid mistakes and at the end you are the hero to the client."

Then you must have some very nice clients, I guess. My experience is that if you sell them broken software, and then repair it, they consider it just normal and expected, nothing special - after all, it's none of their business whether the product got broken by you or by the manufacturer, Microsoft, as long as they have bought it from you.