What do you think about the new licencing policy?

Miklos_Hollender

Bruno,

I tried to implement Mfg at a candle production shop and at a sewing shop and after a lot of headaches and a lot of customizations, when the users didn't even understand the concepts, finally I looked around the Web for the theoretical background of the stuff.

And what I have found is that most the concepts in NAV Capacity Planning only suit "metalworks" companies, like ones who have CNC lathes and so on and manufacture stuff like machinery parts etc. So then I showed NAV to the professors of Transport Engineering at a local university - where half of the university is working at Audi and Audi car part manufacturers - and they really liked it. They said it's very good for car parts manufacturers.

And what I have found there that terms like "Routings" and "Machine Centers" (or, in real life: "homogenous machine centers") are not just ERP buzzwords but very real, very old and traditional concepts in "metalworks" industries, but DO NOT EXIST in other industries, like a sewing shop, beverage productions plant, or at a company who produces windows and doors (they all were prospects for us). They plan capacities completely different ways.

As for Demand Planning, what I call "pull system" is that it thinks the following way: your production is pulled by your sales, and your purchase is pulled by your production. I have never found a company who would work this way. Most of them used a "push" system, which means, like, my sewshop client planned on just paper what kind of clothes to sew in the next year, ordered a kilometer of textile material from China, that traveled on a ship for months, and then just sewed however much clothes they could sew from it. No backorders, no replenishments - because replenishment period would be half a year or so.

Then what's left? Production Orders and BOMs. That can maybe used at any production company, but even that's not sure - some chemical and like companies use recipes in percentages, not quantities...

So I think it's better to handle NAV Mfg as a "metalworks" vertical system and buy or build add-ons for other kinds of production companies: breweries, sewshops, and door manufactureres and so on. Actually for the first two there does exist an add-on for both, I've checked it out.

Miklos_Hollender

Yeah, of course, percentages can be modeled with real units of measures, the problem is not this, but rather that the quantities are not discrete. This causes all kinds of funny problems.

I had a prospect, a chemical factory, who told me the following: materials get shipped to them on rail. Receiving means putting the whole railway carriage on a huge scale and measuring the weight. But that damns scale often tilts into one direction or another, so the measuring is never correct - even their purchase contracts say that 0,5% difference from the ordered quantity is acceptable. And they do not find it out until the want to consume it and then they find it's not enough... and their production mostly consists of boiling this material in huge vessels, and after each boil, the volume of the vessel becomes less and less, because some remaining material sticks to the vessel, until after a dozen or so boils they clean it and it starts again...

bruno77

Miklos,

Very interesting that you say that your client is a sewing shop, since so is one of our clients, and they use Demand Planner for planning preseason and ASAP (as-soon-as-possible) demand, and MRP for generating planned production orders which they use for ATP when taking orders, the planned production orders are also used as demand when purchasing the raw-materials from China (etc.). Note, that a push system includes the forecast, which is expected demand, and is consumed by actual demand (i.e. sales orders in the system), which works great with Navision.

It works like a charm in my case, so again I must say that standard Navision manufacturing is a good platform for this kind of company, at least it worked out very nicely in my situation.

Also, FYI Routings (Operations) and Work Centers are standard APICS (http://www.apics.org) terms, not only used in the metal industry and if I am not mistaken so is Machine Centers. They are definitely used in sewing shops and many other industries as well.

Miklos_Hollender

APICS... gee, APICS might make sense where you live but where I live half of the "production managers" I met with didn't even have a college degree.

OK. Maybe I have to modify my statement: NAV Manufacturing is useful if the client wants to manage their production "by the book", the way it's taught in the school. Maybe this is why I think it works mostly for metal shops: because metal shops tend to be managed by professional engineers while seweries or beer breweries get managed by the nephew of the owner with a high school degree - in my experience, at least.

johnson_alonso

I think Miklos doesn't understand about one of famous key message when selling Navision. It is "easy to customize". I said this because Milos said Navision can only implement in:

"And what I have found is that most the concepts in NAV Capacity Planning only suit "metalworks" companies, like ones who have CNC lathes and so on and manufacture stuff like machinery parts etc"

That's wrong. Navision Manufacturing either foundation and complete traditional MRP/MPS can be applied to various manufacturing industry not only candle and assembling Industry.
To completely understand about Navision as an ERP system, someone must take CPIM (Certified Production and Inventory Management) course and exam. You also have an industrial engineering degree with cumlaude or have a master degree in ERP by research and course



Rgds,

Miklos_Hollender

Complete utter bullshit. I don't know what CPIM is but I did the NAV Manufacturing certification as first in this country (in early 2003), been teaching that to other partners from that time on, had several projects trying to implement it, had at least 10 customized sales demos about it, and had I not decided to move to the UK, I would start teaching it at a local university this autumn.

See, this is all about business, and all businesses depend on sales, and all sales depend on the market.

And if the market wants to manage their production really differently, then all those nice buzzwords like APICS and CPIM and all the smart clever engineering stuff taught at universities ain't worth crap. Everything, always, ever, is decided by the market. Even if the market is wrong, we - and Microsoft - are the providers, the ones who have to build working solutions, not the smartasses who try to "educate" people how to do things the "right way". That's somebody else's job. We have to build and sell solutions, and to sell and to educate are two radically different goals which can never be put under one hat.

Sorry if I sound rude or outspoken but I am really tired of conversations of this type. Don't ever try to convince me to "educate" users, because it's WE who have to sell and do everything for a sale. They don't have to buy. It's a kind of a luxury for them which *might* prove useful.

At least five of the ten customized sales demos I held it turned out that not even NAV Manufacturing, but no other manufacturing systems could fit, because the client did not assign an Item No. to their products but treated them as services, as projects, f.e. one of them was manufacturing custom doors and windows. And then we had no other choice but to drop the whole idea and try to offer some improvisation based on Jobs granules and dozens of days of customization. And even the others had wildly different requirements.

Customization? Manufacturing is one of the application areas of NAV that are very hard to customize. The reason it is so is that for some obscure reason, the decided to base Demand Planning on a horribly complicated mathematical engine in Codeunit Inventory Profile Offsetting, which is about creating a two dimensional matrix of temporary record variables and doing hard-to-understand magic with them, like creating temporary SKU's even if you don't even use SKU's at all - good luck for understanding and customizing that code. Every sane person would have rather written a very simple code of calculating FlowField in Items like Qty. on Sales and Qty. on Production Order etc. and doing very simple arithmetics on them but for some reason they decided to do it otherwise. Maybe if one has 1000 Production Orders a week then this Inventory Profile Offsetting might make sense, because it can be faster, better in performance, but our customers had 3-4 Production Orders each week so speed was meaningless.

One last word about push/pull systems: try to implement that in NAV, that a subcontracted operation of a Production Order, which is reserved for a Sales Order, when the due date for the operation is changed, the shipping date of the SO be also changed... It seems the designers of NAV assumed a customer-focused market where customers set deadlines throughout the whole supply chain. While in reality, at least in our reality, every deadline is set by your vendors and subcontractors.

Why do you think there are dozens of vertical add-ons for mfg. companies? Why do you think that even SAP - which has much more features - routinely sells "Industry Solutions" to mfg. companeis? Think about that. There is no such thing as a "one size fits all" "standard" manufacturing solution.

johnson_alonso

Your answer and your knowledge are virtually like several days putrid and reek humanshit.
I am not impressed that you will teach a local university, except you will teach in MIT, Penstate or UMIST.
As a certified in navision manufacturing, the high school graduate can also take the exam and certified. but the important is you must understand about CPIM too because you will implement navision to a company whose production staff or manager graduate in Industrial Engineering
as you write that you are the first one person certified in manufacturing in 2003, it means that your country is still developing to accept navision. Lack of sensivity.

you wrote:

Don't ever try to convince me to "educate" users, because it's WE who have to sell and do everything for a sale. They don't have to buy. It's a kind of a luxury for them which *might* prove useful.

It's not what I mean that we must educate the client or users. The important is that to make the company use Navision business process or the company's current business process.
So if you don't know the uptodate business process or current business process that most of companies are running right now, you are just speaking big mouth like you do right now.
The customisation is one of method to make navision more adaptable and can be used there.
So do you think the add-on is not one of customisation result.., o you skinhead..? I think it's easy to sell navision in your country because of the knowledge drawback. Here, it's a tough work but exciting to face the challenging.

I'll tell you a little bit about manufacturing but I suggest you must take a course in industrial engineering or industrial technology. Don't use manufacturing manuals only.
1. I see that Navision use Linear Production Model in their production planning.
2. Linear Production Cost Functions
3. One of the earliest production-planning modeling efforts was that of Holt, Modigliani, Muth and Simon (1960), who developed a production-planning model for the Pittsburgh Paint Company.
4. etc (write me to know more the detail of mathematical formulas about manufacturing planning and control, ERP etc)

Customization? Manufacturing is one of the application areas of NAV that are very hard to customize.The reason it is so is that for some obscure reason, the decided to base Demand Planning on a horribly complicated mathematical engine in Codeunit Inventory Profile Offsetting, which is about creating a two dimensional matrix of temporary record variables and doing hard-to-understand magic with them, like creating temporary SKU's even if you don't even use SKU's at all - good luck for understanding and customizing that code.

I don't think so, it's software, not nuclear bomb. I am not scare at the mathematical engine, do you know multiple integral, iteration, etc.., it's more difficult.

One last word about push/pull systems: try to implement that in NAV, that a subcontracted operation of a Production Order, which is reserved for a Sales Order, when the due date for the operation is changed, the shipping date of the SO be also changed... It seems the designers of NAV assumed a customer-focused market where customers set deadlines throughout the whole supply chain. While in reality, at least in our reality, every deadline is set by your vendors and subcontractors.

If you have understood about manufacturing industry interrelation triangle, I think there will no more big mouth here. anyway, how old r u ?


Rgds,
Johnson

Miklos_Hollender

you must understand about CPIM too because you will implement navision to a company whose production staff or manager graduate in Industrial Engineering

Why? If I managed to find a clever client, they would easily understand the features and can easily define whether they want changes or not. Don't believe all the bullshit big-time consulting firms spew about "business procedures". That's for the big enterprises. A the SMB level, it's all about features, not procedures: user X wants a button that generates an order etc.

So do you think the add-on is not one of customisation result

Usually not. Most add-ons try to add new features instead of changing existing ones. Sometimes it's unavoidable, but generally, add-ons keep 90% of their features separate from the standard - usually interface at journal level.

I think it's easy to sell navision in your country because of the knowledge drawback

Do you truly think it's easy to sell people something that's expensive and they don't understand what benefit it gives? When you keep talking about Capacity Planning and the client asks questions like "Ok, ok, whatever, but can this program make employees steal less materials or work faster?..."

I'll tell you a little bit about manufacturing but I suggest you must take a course in industrial engineering or industrial technology.

Why? Our job is to teach clients using software and change it according to their needs. Not to manage a firm. I have found that one can take a developer who never worked with business systems, and teach him in about 4 hours enough of the theory of Financial Accounting in order to be able to implement Financials after reading the manuals. Because it's the user who defines what he wants.

Same stuff for Mfg. When I presented NAV Manufacturing to the engineers on the university, despite that all I know of Mfg. is from the clients, it happened vey rarely that they asked some question that I did not understand at the first try. Once one understands that all business systems are about master data, transactions and summing them up to get reports, no industrial requirement needs more than a few hours to understand.

If you have understood about manufacturing industry interrelation triangle, I think there will no more big mouth here.

Never heard about that, but I don't care. We are again talking of theories instead of market requirements. My client's production greatly depended on subcontractors. It was a bit too costly to implement it. This is all that counts, not the theory.

If I had some spare time, I'd design an add-on myself. Instead of stuff like Demand Planning, it would provide easily accessible, simple answers to questions like "Where is this PO at this moment? Have all materials been ordered? Have them all been received?" - to provide users to really control and manage their stuff without having to hunt around for data.[/quote]

Miklos_Hollender

I've already quited my last job, I got enough spare time

As for age, I'm 28, and I know why Jonson asked it: probably he will write something like "you should work 15 years in the industry before picking up consultancy". I have worked together with such "industrial experts" and they just hasn't been flexible enough.

Once upon a time, we had 12 material Locations, 12 Shop Floors and 12 Finished Product warehouses - 36 locations. And of course the Demand Planning collapsed. And it was before 3.7 so we could not rather use Bins for that, we either implement the full heavyweight WMS or just use Locations. And looking at CU Inventory Profile Offsetting and noticing that horrible virtual-SKU stuff there proved it's meaningless to try to change that code - especially that we would also have need to change Reservations and Order Tracking as well. And in such situations "industrial experts" just collapse and give up, and it always takes the young, adventurous, brave folks to start experimenting with writing a Bin-like granule, or using Dimensions, or rewriting the planning engine with very simple flowfield arithmetics and so on. Hey, it's different now with all the SMB's than those big, slow JD Edwards, SAP or MFG/PRO manufacturing projects of the early nineties that "industrial experts" base their way of thinking on. Nowadays it's always like building a castle out of dried shit, and the only thing it needs is flexibility and dedication.

Administrator

BlackTiger wrote:

GO TO WORK! BOTH OF YOU!

If you have nothing to add to this thread ... then please don't.

Miklos_Hollender

OK, we wandered too far away from the topic of licencing.

I need to explain one more thing and then back to the topic. In the old times, when the web was new and Netscape was a good, successful product, there was a lead developer at Netscape call Jamie Zawinski. Later on he suddenly quited and he explained it as "Netscape was a software people wanted to use. They wanted to change it into a software managements want to buy, kind of a groupware." Interesting observations, these two categories: software people want to use vs. software managements want to buy. This is why the ERP experiences of the eighties and nineties are irrelevant, because in that age ERP clearly was software managements wanted to buy and users ("clerks", as they were called back then) were more or less irrelevant. Nowadays, in the SMB sector, no implementation can be successful if one cannot turn the ERP system into something people want to use.

And now I'm back to licencing. I think most advanced operations granules are clearly not something people would want to use. This kind of value is almost always delivered through add-ons. Therefore, the more add-on friendly the licencing is, the better.

johnson_alonso

BlackTiger wrote:
GO TO WORK! BOTH OF YOU!

Administrator wrote:
If you have nothing to add to this thread ... then please don't.

I absolutely agree with Administrator.

To BlackTiger,
It's not your business to involve someone's conversation here except you post something supporting the conversation, maybe display your knowledge about Navision from your big mouth. (sorry for my rude words but it's solely cause by your uppercase words, it's a sign of big mouth).

To Miklos,
Our debates seems annoying, but I am quite sure with your knowledge in Navision. I guess you are really navision consultant and don't want to load your self with a lot of knowledge outside of Navision manual. It's good if the clients or prospect customer really need and want to speed their IT process and all resources are ready. But if they do't really change their business process to follow Navision standard, it's not wrong if you add some outside knowledge of Navision then can modifiy Navision before presentation to make Navision can fulfill their requirements, and lead them so that there are no many changes ust be done by you.
while you are being not work now, it's the time for that.

Miklos wrote:

Once upon a time, we had 12 material Locations, 12 Shop Floors and 12 Finished Product warehouses - 36 locations. And of course the Demand Planning collapsed

The large enterprise is not Navision part to solve, but it is great plain or maybe axapta. It's clear that one of the webcast available from Microsoft explained about Navision is for midsize company, but I don't know if a modification can increase the status. I think it can't. One of the costing method i.e. average is also confusing one.



Rgds,

Miklos_Hollender

OK, we are starting to understand each other.

There are two possible ways to implement an ERP system 1) change the company to suit the "best practices" represented by the software 2) change the software to suit the current practices of the client, regardless whether they are best or not.

I think Navision was clearly designed for the later approach. If you look at the Navision vs. SAP battlecards downloadable from PartnerSource, they clearly emphasize the later approach. Or if you remeber the old OnTarget methodology, it clearly states that they don't recommend BPR, because people don't like to be "reengineered". I think Navision was never designed - like f.e. SAP - as a software which clearly and strictly represents "best practices" and enforces them. To be able to do that, a software needs mandatory fields, configurable workflows etc. This kind of strictness is missing from Navision. Therefore I think Navision was designed for the later approach. It wants to serve, it does not really wants to enforce anything.

Miklos_Hollender

Average costing is I think a cultural trait, a tradition: almost every German company uses it - and almost nobody outside Germany. IMHO, of course.

Alex_Chow

Miklos Hollender wrote:

Average costing is I think a cultural trait, a tradition: almost every German company uses it - and almost nobody outside Germany. IMHO, of course.

It's popular in the US as well. Actually most distribution companies use average cost.

Traditionally Average cost is easily to keep track of using pen and paper. That tradition kind of carried over to the digital age.

bbrown

There are two possible ways to implement an ERP system 1) change the company to suit the "best practices" represented by the software 2) change the software to suit the current practices of the client, regardless whether they are best or not.

I find that most implementations are usually a compromise between customizing Navision and adapting new business processes. These are usually budget-driven decisions.

Miklos_Hollender

It's popular in the US as well. Actually most distribution companies use average cost.

Yes, it is said that average costing reflects reality better than FIFO. Although if the purchase prices don't fluctuate much it does not really make a difference. And when it does fluctuate I think FIFO is better because then the COGS reflects this fluctuation - Average would "iron out" these. Maybe this is why some companies like Average, COGS is much more plannable - but much less realistic, I think. However, FIFO is easy to repair, because if something goes wrong, one can easily track it back to the purchase entry and revaluate it. Repairing average is much harder. Therefore I usually recommend FIFO just to be on the safe side. Also, I had some wild bug huntings for Average with manufacturing in 3.6, as the Valuation Dates of adjustment entries always sent the average cost out in the wild, but I think it's been repaired in 4.0 SP1.

Traditionally Average cost is easily to keep track of using pen and paper. That tradition kind of carried over to the digital age.

It's an interesting question. Keeping "cost-forwarded" FIFO like NAV does would have been almost impossible on pen and paper - but taking a physical count at the end of the financial year and just looking at the purchase invoices backwards in time until it's total quantity is equal to the current inventory could have been easy I think.

Alex_Chow

Miklos Hollender wrote:

Traditionally Average cost is easily to keep track of using pen and paper. That tradition kind of carried over to the digital age.

It's an interesting question. Keeping "cost-forwarded" FIFO like NAV does would have been almost impossible on pen and paper - but taking a physical count at the end of the financial year and just looking at the purchase invoices backwards in time until it's total quantity is equal to the current inventory could have been easy I think.

Not really. If you're running a very small company, it would've been okay. But if you're doing millions and millions of dollars in business, it becomes a hassel. Of course, the CPAs also recommend averge costing since it's easier for them to do their books for the company.

Miklos_Hollender

Okay. Anyway, actullay, as a kind of historical hobby, I'm really interested in how accounting was done before software - even before textfiles on mainframe computers summed up with COBOL programs - were used. Don't happen to know some historical website about it?

themave

Miklos Hollender wrote:

Okay. Anyway, actullay, as a kind of historical hobby, I'm really interested in how accounting was done before software - even before textfiles on mainframe computers summed up with COBOL programs - were used. Don't happen to know some historical website about it?

Accounting was done on ledger books, you have a ledger to records sales, a ledger to record expenses. It wasn't that long ago. my high school accounting class in 1978 didn't use any computers, it was all double entry accounting in ledgers

Miklos_Hollender

Hm. I was born in 1978...

Alex_Chow

Miklos Hollender wrote:

Okay. Anyway, actullay, as a kind of historical hobby, I'm really interested in how accounting was done before software - even before textfiles on mainframe computers summed up with COBOL programs - were used. Don't happen to know some historical website about it?

It's done with mountains and mountains of papers.

themave

Miklos Hollender wrote:

Hm. I was born in 1978...

Ouch ](*,) I was born in 1961, at least I still play video games 8)

kriki

[Topic moved from Upcoming version NAV 5.1 forum to Navision forum]

TommyValentine

Any new information on the licencing policy?

My boss took a course and he still doesn't understand sh :oops: t...

Alex_Chow

It's based on users now.

You get a list of granules depending on if you purchase the Advance Management or the Business Essential edition. All this is explained on the Navision pricesheet.

themave

I get the new license, but how are current installations transitioned to the new, what credit do we get.

for instance we license most all the granuls, except manufucaturing. pretty much everything that is in the Advanced management package (but not quite everything), in addtion to responsibility centers, which is not included in the advanced management package.

so, if we want to switch to the new license, and get the few items we don't currently have. what do we pay ? How much credit for the current license do we get. I realize you can't give a dollar amount, but is it based on a formula, like you paid this much for your license, the new advanced user license for 34 users cost this much, so you pay the difference.?

Alex_Chow

If you have a credit as a result of the transition, MSFT operates on a "use it or lose it" policy. So if you have a credit, might as well get another new user.

I haven't seen much benefit moving from MBL to BRL at this point. It seems that the customers will be paying more to get the BRL license when everything is running okay.

andrejsm

There is some new documents with rules about transition from old licencing policy to BRL in the partnersource. BRL essentials licensing is better for small companies ( <15 users). But (what a surprise :evil: ) licence migration is not for free.

TommyValentine

Any idea on how much it'd cost?

Meeting with customer on Monday and we need to tell him SOMETHING about the costs of NAV...