Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.7K 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
- 317 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.6K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Following the paradigm change in ERP: make Navision simpler!
Shenpen
Member Posts: 386
In the recent years, the ERP paradigm has shifted: from the big enterprise to the SMB, from organized companies to chaotic ones, form generally accepted business practices to individual performance etc.
Software MUST follow it.
Here come some of my biggest pains experienced working with Navision and
it is actually a suggestion for the core developers for Navision 5.0.
To put it short: optimize for the common case.
To put it long:
If we look at ERP software or actually any kind of business operations
software (like CRM, SCM etc.) what are they actually?
A) They consist of a database with forms and reports.
On top of it, there is program code that just copies data from one
table to another.
From an order to a shipment, from a shipment to an invoice, from an
invoice to a G/L Journal
(in the background Navision does this), from a journal to a ledger,
most of it is just copying data.
C) Complicated business logic that does complex things like Inventory
Cost Adjustment, Reservations,
Item Tracking, and Capacity Requirements Planning.
Some software, like MS CRM have mostly just "A". What to say?
Our internal users don't exactly like it... well, but they got used to it.
But of course I am not in favor of "A" kind of software - but I say that "A" + "B"
is enough and you don't need "C", because it causes more harm than benefit.
Navision has "A", "B", "C".
The interesting thing is that on all our projects users were totally not
interested in "C". What they loved are those useful things like "Explode BOM" function on
Sales Order - and
when we developed, with very little efforts, similar useful functions
like "Explode Variants"
on a Purchase Order (insert all variants of one item) or we coloured
(also on PO) the Description
bright red if the Item was not assigned to that vendor in the Item
Vendor functionality.
Or a function that puts all the inventory of a Location on a Transfer
Order. Or a function
that puts all the inventory of a Location on a Negative Adjustment (to
empty those scrap locations).
These are easy things, ten minutes of programming and what we get
were really happy users, which I thought before was totally impossible with Navision.
And all the times we ran into explaining all those complicated features
of "C", after hours
and hours of speaking and presenting and making people more and
more confused, what we got
in the end was something like:
"No, thank you, we don't need that, we just want to see some
numbers here and there
and that's it. We don't need Reservations, just a figure somewhere
showing Qty. on Sales Order - Inventory,
and we don't need this terribly complicated costing engine, just some
realistic Standard Costs,
and we don't need Item Tracking, we will create individual Items
instead, and for capacity... what's exactly
that? I don't even understand that. It seems to be thinking in capacity
in minutes, while we are thinking
in capacity in pieces."
So why do we need all those complicated features in "C" that make
Navision expensive and they only thing they do is to confuse users and induce
bugs?
Let's take a closer look on them.
Item Tracking:
In some older Navision version (maybe 2.6?) Lot No. and Serial No.
appeared as a new function. In that version,
these were just new fields on documents and journals and ledgers. So
if you wanted to buy 100 items with serial no.,
you had to enter 100 order lines. This sounds like a bad thing, but if we
think logically:
it is very easy to write a function, where you enter a number, let's say
100, and it copies
the order line 100 times. Easy, isn't it? Another development you need
is to create a checkmark
on printed documents to group items by Item No. and don't show
individual lines. That's also easy, and with
these two small developments we would have a simple, easy-to-
understand system. It would be very user-friendly,
because remember: user-friendly does not mean you don't have to
work much, but it means you don't have to
think much, you don't have to understand concepts that are beyond
the scope of your job. Most users are more
than happy to do more manual work and less thinking, because that needs less responsibility and causes less stress.
So they had this bright good and simple idea, which would become really useful for this two little
modifications if they would have done them. But what did Navision A/S (it was around 2000) do instead?
Introduced this overly complicated way of Item Tracking we know today.
If you download the white papers, you can even see that the first try was so complicated that actually it did not work.
So why did they exchange a working, simple idea for a complicated one? I completely don't understand.
Reservations:
Current reservations engine with it's accounting-style double-entry system is wonderful from a theoretical viewpoint.
You can reserve half of a Sales Order line of stock and other half of manufacturing, and then reserve the materials on
Purchase Order for the manufacturing Production Order and whatever. I think all the theoretical experts on the universities love it.
I also loved it before my first project. The problem is that users don't understand it. From the users viewpoint, you either
reserve stock, or order products/materials not for stock, but for a customer, and that's it. It is too complicated.
And because of this complexity, it is very, very hard to implement customer-priorities based reservation, which is actually
a very basic and often needed requirement. I saw one NSC try it. It was the typical "flying blind, upside down" situation. Really hard.
How would a simple, but good reservation system look like? You would have customer priorities. You could configure the prioritiers of
other sources of demand, such as Transfer Orders etc. Just simple integer fields. And NO Reservation Entry table - and before
every shipment (or any negative inventory movement or any kind of warehouse movement), the software would calculate the waiting line and decide whether you can
ship it or not. (It would not be slow - it is exactly the same logic as the Item Application Entry that Navision does at
every stock movement.) And that's it. You don't need to reserve anything else but stock. If you manufacture or buy products directly for customers,
you could just simply use something like Drop Shipments or Special Orders and develop some similar stuff for manufacturing too.
You don't have to do all this complex logic. What I described here is the common case, the 90% - let all those 10% buy development
and not force us consultants to do free development for the 90% - because when development is not adding something but is
taking away something to make the software, it usually has to be free, because from the customer's viewpoint, it is the fix of design bug of usability.
You can always charge for making the software more clever, but to make it more simple, it is almost impossible. So please make Navision
simpler and remember, optmize for the common case!
Inventory Cost Adjustment:
Yes, I know that Costing is the Holy Cow of many accountants, but accounting in itself is important only for those enterprises
that are big enough to have no other ways of measuring performance. For the SMB sector, accounting plays a rather secondary role,
often outsourced. Yes, I know that our past experiences still have a strong effect on us consultants, from those old times
where the Chart of Accounts was the bone and flesh of ERP, but not it is different, now operations is everything and many companies
would happily trade Accounting Schedules for a decent bar code label printing granule or a purchase request confirmation workflow.
So, if it is not the accountants, but the Operations/Logistics/Sales Manager, who decides the requirements of the implementation project,
what does he/she say of Costing? "Gimme realistic costs and realistic margins. I don't care whether you call it FIFO or Average
or whatever, it just be realistic, to have realistic margins calculations."
They don't accept that if an accountant makes a mistake and posts a 1000000 EUR invoice as 100000 EUR, you can throw all your wonderful
business analyses out of the window until they correct it, which depends on whether they notice it or not. This costing
solution is so brittle.
I have myself repaired at least three serious bugs in Inventory Adjustment in NAV3.6 . From 3.7A on it seems to be correct
- until the next big idea makes the whole process start over again. And every consultant or accountant who investigated
wrong item costs through endless Item Application Entries and found a Positive Adjustment on wrong costs two years ago
longs for a simple, and sound costing solution.
And the right, simple solution - Standard Costing and creating a different Item No. or Item Variant for every change of purchase price
with a very simply copy function - was there 30 years ago. So why to have this needless complexity?
And yes, the FIFO. FIFO is a clever thing. I was taught in school that FIFO and the others were introduced because if
you had stock of the same item on different purchase priceses - however rare it is in the real life - you have to
estimate the costs, because there is no way to tell that which purchase moved out first. But it was the before ERP.
Now, you not only can tell which purchase moved out first, but you HAVE TO move out the first purchase first,
because your product either has an expiry date or a warranty date, and for the later, you will want the warranty period you
get cover as much a percentage of the warranty period you have to provide as possible. So, FIFO (or FEFO, or FWFO) should
be a warehousing function, not some kind of theoretical cost estimation. If Item Variants had different Standard Costs
(now it is possible only with the very complicated SKU function), and there would be a simple copy function to use
on every purchase price change, you could either choose which variant you sell or it would automatically FIFO-ed out
on every shipment with also a very simple function - and that's it!
Remember, please, that we are consultants. We love to play around with Navision. But for users, it is just another burden
on their backs, and they think like "Hey, I don't want to understand it, just tell me what fields to fill."
Now it is time for Microsoft's famous usability expertise to move in. Make Navision simple, easy to understand and optimized
for the common cases, please!
Remember, the goal is: let we, constulants, only do customizations that ADD, and not be forced to do customizations to TAKE AWAY.
Software MUST follow it.
Here come some of my biggest pains experienced working with Navision and
it is actually a suggestion for the core developers for Navision 5.0.
To put it short: optimize for the common case.
To put it long:
If we look at ERP software or actually any kind of business operations
software (like CRM, SCM etc.) what are they actually?
A) They consist of a database with forms and reports.
On top of it, there is program code that just copies data from onetable to another.
From an order to a shipment, from a shipment to an invoice, from an
invoice to a G/L Journal
(in the background Navision does this), from a journal to a ledger,
most of it is just copying data.
C) Complicated business logic that does complex things like Inventory
Cost Adjustment, Reservations,
Item Tracking, and Capacity Requirements Planning.
Some software, like MS CRM have mostly just "A". What to say?
Our internal users don't exactly like it... well, but they got used to it.
But of course I am not in favor of "A" kind of software - but I say that "A" + "B"
is enough and you don't need "C", because it causes more harm than benefit.
Navision has "A", "B", "C".
The interesting thing is that on all our projects users were totally not
interested in "C". What they loved are those useful things like "Explode BOM" function on
Sales Order - and
when we developed, with very little efforts, similar useful functions
like "Explode Variants"
on a Purchase Order (insert all variants of one item) or we coloured
(also on PO) the Description
bright red if the Item was not assigned to that vendor in the Item
Vendor functionality.
Or a function that puts all the inventory of a Location on a Transfer
Order. Or a function
that puts all the inventory of a Location on a Negative Adjustment (to
empty those scrap locations).
These are easy things, ten minutes of programming and what we get
were really happy users, which I thought before was totally impossible with Navision.
And all the times we ran into explaining all those complicated features
of "C", after hours
and hours of speaking and presenting and making people more and
more confused, what we got
in the end was something like:
"No, thank you, we don't need that, we just want to see some
numbers here and there
and that's it. We don't need Reservations, just a figure somewhere
showing Qty. on Sales Order - Inventory,
and we don't need this terribly complicated costing engine, just some
realistic Standard Costs,
and we don't need Item Tracking, we will create individual Items
instead, and for capacity... what's exactly
that? I don't even understand that. It seems to be thinking in capacity
in minutes, while we are thinking
in capacity in pieces."
So why do we need all those complicated features in "C" that make
Navision expensive and they only thing they do is to confuse users and induce
bugs?
Let's take a closer look on them.
Item Tracking:
In some older Navision version (maybe 2.6?) Lot No. and Serial No.
appeared as a new function. In that version,
these were just new fields on documents and journals and ledgers. So
if you wanted to buy 100 items with serial no.,
you had to enter 100 order lines. This sounds like a bad thing, but if we
think logically:
it is very easy to write a function, where you enter a number, let's say
100, and it copies
the order line 100 times. Easy, isn't it? Another development you need
is to create a checkmark
on printed documents to group items by Item No. and don't show
individual lines. That's also easy, and with
these two small developments we would have a simple, easy-to-
understand system. It would be very user-friendly,
because remember: user-friendly does not mean you don't have to
work much, but it means you don't have to
think much, you don't have to understand concepts that are beyond
the scope of your job. Most users are more
than happy to do more manual work and less thinking, because that needs less responsibility and causes less stress.
So they had this bright good and simple idea, which would become really useful for this two little
modifications if they would have done them. But what did Navision A/S (it was around 2000) do instead?
Introduced this overly complicated way of Item Tracking we know today.
If you download the white papers, you can even see that the first try was so complicated that actually it did not work.
So why did they exchange a working, simple idea for a complicated one? I completely don't understand.
Reservations:
Current reservations engine with it's accounting-style double-entry system is wonderful from a theoretical viewpoint.
You can reserve half of a Sales Order line of stock and other half of manufacturing, and then reserve the materials on
Purchase Order for the manufacturing Production Order and whatever. I think all the theoretical experts on the universities love it.
I also loved it before my first project. The problem is that users don't understand it. From the users viewpoint, you either
reserve stock, or order products/materials not for stock, but for a customer, and that's it. It is too complicated.
And because of this complexity, it is very, very hard to implement customer-priorities based reservation, which is actually
a very basic and often needed requirement. I saw one NSC try it. It was the typical "flying blind, upside down" situation. Really hard.
How would a simple, but good reservation system look like? You would have customer priorities. You could configure the prioritiers of
other sources of demand, such as Transfer Orders etc. Just simple integer fields. And NO Reservation Entry table - and before
every shipment (or any negative inventory movement or any kind of warehouse movement), the software would calculate the waiting line and decide whether you can
ship it or not. (It would not be slow - it is exactly the same logic as the Item Application Entry that Navision does at
every stock movement.) And that's it. You don't need to reserve anything else but stock. If you manufacture or buy products directly for customers,
you could just simply use something like Drop Shipments or Special Orders and develop some similar stuff for manufacturing too.
You don't have to do all this complex logic. What I described here is the common case, the 90% - let all those 10% buy development
and not force us consultants to do free development for the 90% - because when development is not adding something but is
taking away something to make the software, it usually has to be free, because from the customer's viewpoint, it is the fix of design bug of usability.
You can always charge for making the software more clever, but to make it more simple, it is almost impossible. So please make Navision
simpler and remember, optmize for the common case!
Inventory Cost Adjustment:
Yes, I know that Costing is the Holy Cow of many accountants, but accounting in itself is important only for those enterprises
that are big enough to have no other ways of measuring performance. For the SMB sector, accounting plays a rather secondary role,
often outsourced. Yes, I know that our past experiences still have a strong effect on us consultants, from those old times
where the Chart of Accounts was the bone and flesh of ERP, but not it is different, now operations is everything and many companies
would happily trade Accounting Schedules for a decent bar code label printing granule or a purchase request confirmation workflow.
So, if it is not the accountants, but the Operations/Logistics/Sales Manager, who decides the requirements of the implementation project,
what does he/she say of Costing? "Gimme realistic costs and realistic margins. I don't care whether you call it FIFO or Average
or whatever, it just be realistic, to have realistic margins calculations."
They don't accept that if an accountant makes a mistake and posts a 1000000 EUR invoice as 100000 EUR, you can throw all your wonderful
business analyses out of the window until they correct it, which depends on whether they notice it or not. This costing
solution is so brittle.
I have myself repaired at least three serious bugs in Inventory Adjustment in NAV3.6 . From 3.7A on it seems to be correct
- until the next big idea makes the whole process start over again. And every consultant or accountant who investigated
wrong item costs through endless Item Application Entries and found a Positive Adjustment on wrong costs two years ago
longs for a simple, and sound costing solution.
And the right, simple solution - Standard Costing and creating a different Item No. or Item Variant for every change of purchase price
with a very simply copy function - was there 30 years ago. So why to have this needless complexity?
And yes, the FIFO. FIFO is a clever thing. I was taught in school that FIFO and the others were introduced because if
you had stock of the same item on different purchase priceses - however rare it is in the real life - you have to
estimate the costs, because there is no way to tell that which purchase moved out first. But it was the before ERP.
Now, you not only can tell which purchase moved out first, but you HAVE TO move out the first purchase first,
because your product either has an expiry date or a warranty date, and for the later, you will want the warranty period you
get cover as much a percentage of the warranty period you have to provide as possible. So, FIFO (or FEFO, or FWFO) should
be a warehousing function, not some kind of theoretical cost estimation. If Item Variants had different Standard Costs
(now it is possible only with the very complicated SKU function), and there would be a simple copy function to use
on every purchase price change, you could either choose which variant you sell or it would automatically FIFO-ed out
on every shipment with also a very simple function - and that's it!
Remember, please, that we are consultants. We love to play around with Navision. But for users, it is just another burden
on their backs, and they think like "Hey, I don't want to understand it, just tell me what fields to fill."
Now it is time for Microsoft's famous usability expertise to move in. Make Navision simple, easy to understand and optimized
for the common cases, please!
Remember, the goal is: let we, constulants, only do customizations that ADD, and not be forced to do customizations to TAKE AWAY.
Do It Yourself is they key. Standard code might work - your code surely works.
0
Comments
Independent Consultant/Developer
blog: https://dynamicsuser.net/nav/b/ara3n
Do It Yourself is they key. Standard code might work - your code surely works.
If you think I have problems with Navision development please take a look at this download I wrote (drop a mail to that address if you don't believe): http://www.mibuso.com/dlinfo.asp?FileID=515
So please let's not start a "who's the greater C/AL hacker" compo 'cause y'got no chance
But. The problem is the following: developments should be charged. And if you add complicated functionality to a simpel system, it is very easy to convice the client that it is an extra and they should pay for it. BUT if there is a complicated, hard to understand, hard to use function, and you develop to make it simpler and more error-prone, it is almost impossible to charge.
This is why a simple standard system is better.
You know our biggest competition is SAP B1 and I am afraid that they will beat the living sh*t out of us: because in B1 there is nothing to take away, only to add. Hell, I just read the help file and it was simpler and easier to use than a 1000 EUR local invoicing-and-warehousing software...
And Open Source is also coming, just look at tinyerp.org - amazingly simple.
And the interesting thing is that Microsoft is starting to understand it. I have seen the presentation of Small Business Edition of MS CRM 3.0 - exactly this logic I presented here.
As for costing, please, get a life. Your approach is theoretically correct, but in the real world user f**k up inventory value by careless Positive Adjustments and botched Purchase Invoices (forgetting Currency Code etc.) and especially botched Credit Notes that margins differ by +-60% at least from the real figures. Standard Costing ensures that you won't really have a deviation from the real figures more than about +-5%.
All this theoretical stuff about Average vs. FIFO inventory value or whatever is no more that +-3-4% diference between them.
But the real solution is so simple! 1) Allow different unit cost for Item Variants without using SKU-s. 2) Let users create a new Variant for every purchase price change with a simple copy batch job. 3) Let's write a simple batch job that if you pick an Item without Variant Code, it autogenereates the pick by physical Variant FIFO or FEFO - and then you not only have right costing, but also implemented a very important FMCG warehousing requirement as well.
Yes, I can do it in a day at most, but I am tired of constant merging of service packs with Beyond Compare... So I wish it be standard.
Do It Yourself is they key. Standard code might work - your code surely works.
Do It Yourself is they key. Standard code might work - your code surely works.
... while in reality most of my Navision users are running around in dirty warehouses, sometimes stopping for a minute at a desk, at a gluey keyboard and a dirty, barely-functioning 14'' monitor with tiny font sizes that they can barely see what's on the screen, to randomly click around everything in a hurried way and utter many curses until the manage to Receive some goods and then run around again... how could I expect the to check the Unit Cost when they make a Pos. Adjustment?... this is what Microsoft will never understand... they so accustomed to luxurious environments... sometimes I find myself wishing we would be still having Navision DOS...
Do It Yourself is they key. Standard code might work - your code surely works.
RIS Plus, LLC
I have been complaining about Navision a lot of times, but I get the feeling that if it were up to guys like you it would even be worse. Are you sure you want this very Forum to exist ? After all, guys like me come here to learn something so that we can do it ourselves instead of paying an NSC for that. From you point of view, this had the same effect to your business as the existance of TinyERP has.
Anyway, while I'm not such a fan of OSS, I don't buy their central theme that everybody can enhance any product and that we'll all get better by that, I don't think that it is such a big threat to people doing ERP consultancy/implementation. After all, you guys make money by translating business knowledge to an ERP system. You could just as well make money by translating this knowledge to TinyERP.
Yeah right, do it quick and dirty, no need to implement something in way that is maintainable. Do you know what Agile means ?
Look it up : http://www.webster.com/cgi-bin/dictionary?book=Dictionary&va=agile
Modern businesses need to be agile, because their markets are changing all the time. An ERP should reflect that agility. That only works if you have well thought-out code that is resistant to change without turning into unreadable spaghetti after the third revision. So if there's something we need in Navision it is more agility, and that can only be accomplisghed by a development environment and language that can produce maintainable and refactorable code.
I'm new to Navision (but very old on programming!) but one of the thing i like the most about Navision is Standartization.
And thats the main problem in C!
Its easy to produce standards for Data, Forms, Reports, Copying Data, etc...
Its almost impossible to produce standards for Business Logic.
I dont know enough Navision to argue about the implemented Business Logic but i'm sure that it deserves to be standartized! (sorry for bad english :-))
My idea is that consultants dont need to reinvent the wheel everytime that they get a new customer!
Could it be simpler?! Yeah probably. But are we talking about simple things? BIG NO!
"C" does not cause harm if u do it Navision way. It shows a "way" to do things. I'm assuming that Navision guys took a lot of time thinking about it and of course is one solution. I would change things to my liking if i could. But i prefer to use a standart thats "almost there" and tweak it than to create code that does it like i like it and takes me months to do it. Agility is also measured in time. My clients (non Navision) need things yesterday not 6 months from now.
One last thing - I HATE OSS/Free Software. OSS/FS is killing the business. Not because the OSS/FS paradigm is bad. Its kind of cool actually. Its just because of who uses it. It will eventually do a lot of harm to a lot of businesses.
My argument is just one:
OSS and Free Software is mostly supported by the University folks. They do it part time. They dont get payed for doing that (students,teachers,etc). They get payed to do something else (study, teach). Their income comes from state or familys.
So they can give away software. It costs them nothing to do it. It costs them nothing to donate their work. They were already payed to do something else.
I think the next step is Free Consultants. Imagine every step of the business being documented and posted in the Net so that everyone could see every little detail of the process. And Free!
U would only get one client: the first!!!!
Sorry for the long post.
Summary
"C" is the hard thing to do or to build standarts for
Dont Re-invent the wheel (Microsoft already invented a Hexagonon - use it!)
Either the world becomes a comunist regime and everything is free (unlikely) or OSS/FS will eventually kill the industry
PS: OSS/Free Sofware Fanatics - im not saying that OSS/Free Software is BAD software. I'm just saying its bad and unfair business. And i do know the diference between the 2!
All I can say that you both don't understand the psychology of users.
When guns were invented, swords were there for centuries, and even now they are there in the form of bayonettes. And the reason is simple: people won't trade something that works for something that might work.
Sun StarOffice as a sold, paid product has an amazingly high penetration in the United States - something like 18% ? I don't remember the exact figures. All this users could download and use OpenOffice for free, it is almost the same - StarOffice is but a handful of small chromes added to OpenOffice, and documentation and support. So why don't they use OpenOffice for free?
Simply because of the psychology: Sun as a big, established company promises StarOffice to work, and backs it up with heavy marketing and whatever, while no one ever promised OpenOffice to work. It works, but there is no one to promise it. The product is almost the same, but the psychology is different - OpenOffice is a software, StarOffice is a solution - just the packing, marketing, documentation, support, whatever, in short: the PROMISE is enough to turn a software into a solution.
No one will try to download and implement an OSS ERP, because there is no promise. They want a guy, me, you, any of us to go there, smile, and promise - in a professional way of course - that "Just gimme $100.000 and you will have a wonderful system in 6 months." And then of course live up to that promise.
Users, companies want to outsource responsibility. They want a vendor, an implementor, who can be held responsible for the general succes no matter what.
We have many Microsoft System Enginers and the interesting thing is that they do projects similar to our ones. I never understood - what the hell do you have to implement f.e. for a Small Business Server? Why do they call that a project? Just install it and it works. But then I understood: implementation means taking the responsibility, mean guaranteeing the success, means offering a solution instead of a software.
So implementation services will NEVER die. There is no such thing as free responsibility.
Do It Yourself is they key. Standard code might work - your code surely works.
I've been looking for a source on penetration rates off non-MS office suites but I couldn't find it anywhere. Could you possibly remember where you found this figure ?
I would say that learning to develop Navision has two steps. First just copy some standard function that does similar things what you want to do and modify it. The next step is understanding what's wrong with Navision development standards and consciously not following it. And it is one word: usability.
When I develop, I never use menus, just big buttons with big red bold captions so users really cannot forget to push them. I usually create workflows on forms: for example a Purchase Order receiving workflow is having 3 captions on the bottom on the form: 1. review quantity to receive 2. Enter Vendor Shipment No. 3. Review Posting Date. And then the 4th workflow item is a big button called "THEN PUSH ME", which runs the same code as the Post menu item, but without the stupid question of receive or invoice or both.
And what do I have? Really happy users - before I invented these workflows, user usually hated Navision, because they did not understand it.
So for the UI, you have to break the standards - in all other cases, the standard is fairly OK.
We do talking about simple things is we drop the theoretical approach and look at reality. Man, I tell you a story. Managing Bins in warehouses was amazingly complicated in Navision 3.6 - either you used the full WMS or nothing. And then a subsidiary of us called me - it was my previus employer, an international ERP consulting firm - that the a**holes configured 36 Locations in one physical location and the of course the MRP engine got completely crazy. So I was pissed of and I wrote kinda Bins granule in one evening, integrated with Manufacturing and whatever. OK, a long evening
Why not? Of course not by hand. Either a simple copy function or even more, if you enter a PO and the price is different, it could automatically generate a new variant for you. It's kind of one hour of work to program it, including one coffee and two cigarettes in that hour
OK it might be not OK if the discounts given always change by negotiations. But then we can do that we forget the stupid accounting rules and don't include the discount in the inventory costs - from a business operations perspective, it is not related with the item, but with the skill of our purchaser. Yeah I know this idea scares accountants, but anyway, many companies are doing exactly this - with standard costing.
It's just paradigm change in thinking: in 2005, ERP is not accounting software but operations software, business process automation software. It is because now we are at an SMB era and SMB-s don't care about their usually outsourced accounting - what they are interested in is business operations automation.
Come here, to the wild wild east
Do It Yourself is they key. Standard code might work - your code surely works.
The important thing is to understand that closed-source vendors do exactly the same - if there is a good idea in the new version of MS SQL, it will appear in the new version of Oracle too. And vica versa. Oracle invented SOA (Service Oriented Architecture) and now it's the next fashionable buzzword at Redmond too.
Most OSS projects don't have the same 15-20 years of history as Windows or Oracle. So first they have to implement the existing good ideas and then they can start to think about new ideas. It's about nowadays that new ideas started to appear - just look at KDE 3.4
The important thing is: when closed source vendors copy, they duplicate the efforts. But once there is a stable, usable OSS version, then everybody else who has some big new idea, doesn't have to start everything from scratch, but can build on the existing code base.
When Sun opened up Netscape and renamed it Mozilla, look what happened - we have now Konqueror for KDE users, Galeon for GNOME users, and Firefox for everybody who likes MSIE but wants to have an improved version. And this all are Mozilla-based. And if you have the next big idea to put into a web browser, you just take Mozilla or Firefox and put it there.
If OSS would not exists, huge companies have total monopoly of software development, because no matter how many good ideas you have for a browser, database engine or whatever, you are likely not have the resources do write it from scratch.
But if you have some big ideas in database engines - actually I do... - then there is Posgres to put it there.
And this is simply the best leverage knowledge and effort can get.
Do It Yourself is they key. Standard code might work - your code surely works.
Did i desrespect u ? If i did i'm truly sorry.
I didnt quite get the scope of your post.
To the rest of the discussion:
The point about "outsourcing responsability" is very good. Good input.
About OSS -
Ok. But who is selling the idea? And y would u want someone to develop upon your work if u werent payed for your work yet?
I just dont get it.
Why just not end copyright!! Everything that is produced becames public property the minute it is produced. So that everyone can improve on that idea.
Every book is copied freely so everyone can read it (or add a chapter), every song is on mp3 for everyone to download, every designed arquitecture is copied all around the world, every restaurant chef shows his secrets for a beautiful cooking, every slogan is copied (and added a new idea)
Everything is of everybody.
To be honest this is a very good idea...
... but it just doesnt work.
Remember USSR !?
Not kidding. Actually this is what many people including me are trying to achieve here on this forum.
Just look at these topics of mine:
Tricks to protect Inventory Value
Improving usability with colors
Some tips about user rights
The big decision is the following: do you want to try to be successful by hiding information from others or by sharing it?
There are two reasons for sharing: one ethical and one business reason.
The ethical reason is that for it took more than a year of heavy sweating to learn to implement Navision with weeks and weeks spent working overnights and losing 15kg of weight in two months and whatever. I feel to be ethically obliged to try to save others from the same heavy suffering - or even worse. I don't want to look proud but I am sure that if it were not me, the projects had fallen - not because I am so damn clever but I am lucky enough to have a "never, ever, ever give up" kind of mentality. And I feel that I must help not just to prevent their suffering but also to prevent their falling. And now if you think "OK, of course people help each other but for professional help, there should be a charge", the answer is a fat big NO. And the reason is simple: it's not the greasy managers, but the 22-years old graduate consultants who have the suffering part of the job for $800 a month and they don't allowed to buy professional help and they are not able to convice the above-mentioned managers to sacrfice some money to make their lives a bit lessr hellish.
The business reason is the following: marketing. If you want to make money out of hiding information, you have to connvice people that this information is worth buying. Spending lots of money and lots of sweat to find people who may be convinced that your information is worth buying and maybe even then it is possible that they won't be convinced.
But if you give away information freely, and this is worthwile, important professional information, some people might think "Oh, this guy is so clever, he solved 3 out of our 8 problems - let's pay them to solve the others!" And three topics like the ones I linked here up there can also be a big boost on salary negotiations if you have to change employers and find another NSC to go to.
And the big secret is the following: no matter how many problems you solve and how honestly do you document them on the web, there will still be more and more and more other problems - the number of problems human beings can create is infinite - , and you can get paid to solve them because those documented solutions convince them you can do it.
Sharing is good for business. The more you give, the more you will receive. Always and ever, because - however strange it may sound - ethics and compassion is not just a social creation, but the basic law of the universe itself. Something like gravity - both of them derives of the same natural law that all things are interconnected so they can flourish only if the aware of this connection and help each other. Sorry if it sounded too spiritual.
Do It Yourself is they key. Standard code might work - your code surely works.
If you look at the country flag besides my name I think it looks logical that I might have a little bit more experience of communism than you can supposedly have, isn't it right?
What they called communism was actually a state capitalism. No freedom, no sharing, no helping each other, no common property, no common goods, just a state that owned everything like a monopolistic entrepreneur without any competition. It is simply the worst possible form of capitalism. It was not about the abolition of property but the centralization of property into the hands of one monopolistic, supressing market player: the state. One bureaucracy owned everything.
But no, rest assured, the sharing culture, the gift culture is not about the abolition of property and property rights - it's about a free and conscious decision of sharing your property rights on information as information can be infinitely copied and many other people can benefit from it, and you yourself can greatly benefit from the feedback and contribution.
The first thing to understand that software development is always a kind of research, and there is two kinds of research: scientific (the standards) and business (their implementation). For example, the general theory behind loudspeakers is scientific research, but Maxxtro SP41Q speakers are a product of business research. Do we agree at this point?
It is common in all branches of science that scientific research is either mostly naturally shared by others or if is an invention of a company, they quickly lose their monopoly on it - I don't think every photocopier manufacturer pays a royalty to Xerox.
Of course business research is private property.
Now, the idea of an office suite, an SQL-based database engine, an OLAP-server is scientific research. The implementation of the idea is business research.
Get the point? This is why the EU is against software patents. The idea of OLAP or whatever can't be a private property. The implementation of it can be.
There is nothing wrong in finding a nice function in a software and include it in your own as long as you don't steal the code, but implement it yourself. While business research should always be remain private property and sharing it is to be the decision of the one who pays the bills for the research, scientific research must be a common good, available for everyone. This is why standards like the SQL language specification were invented.
Even Microsoft, the "king of secrecy" understands it - this is why they opened up .NET so others can write Mono and IronPython, this is why they promise that next version of Office will save everything in a completely open XML format etc.
Do It Yourself is they key. Standard code might work - your code surely works.
Do It Yourself is they key. Standard code might work - your code surely works.
To much to anwser this will take a while (man u write fast!!!)
Once again very good rebate!
What i'm saying is that if everyone offers their services/developments then none will buy ziltch because everything is free.
You are stating a political/marketing technique - buy one get one free (or get 3 free buy 5 in your case).
That is done for ages! I'm not talking about that. I'm talking about giving everything free and never getting nothing in return because there isnt anything to get except a good feeling about yourself.
Y do u help people on this forum ? Because u want to help them or because u want to feel good for having helped them? (feeling spiritual also .. sorry)
These are goods ideas, but will never work because human are selfish.
Let me give u an example that Carl Sagan and Ann Druyan gave in a book called Shadows of Forgotton Ancesters (title translation from portuguese to english didnt bother to go to bookshelf)
Imagine that a kid in New Zeland got hit by a car and u read about in the Newspaper.....
Now imagine that it was someone close to u....
Diferent feelings!?!?
This has nothing to do with superior feelings or God or whatever.
Its just printed in our genes.
The main problem is that humans dont bother about people they dont know. Humans if possible will steal and cheat and rob specially if they dont know who they are robing, cheating or killing.
Maybe not u. Maybe not someone u know. But the truth is that people DO rob,kill and steal. So who are they?!?!?
In my modest opinion (i'm just an electrical engineer not a poltitian or historian) the "system" has to be very well regulated. The problem is that freeing everything is probably too big for the system to handle and will crash it. Will there be enough dumping to prevent oscilation? Dunno
About the USSR remark.
(didnt mean to ofend anyone - didnt notice your flag but ....)
What u wrote IS PRECISELY MY POINT!!!! - Under a cloak of freedom they acted.
As u can see i'm portuguese. My country also suffered dictatorship for about 50 years. Right wing. The same principles were in order - "this solution is better" they said. "We need to organize and get better" they said..... Same results. My country is still (as yours is probably) paying for the lost years.
Freedom doesnt come from having things for free. Freedom comes from deserving the things u have (and includes all abstract feeling also!!!!).
(Man this is getting toooo spiritual!!!!)
It doesnt matter to me that people share their knowledge/scientific/cultural/business - just please dont steal my salary by giving away what i do just because u got some other job that gets your bills payed. I dont. Is this selfish? Sure his.
Rember Edison and the light bulb. He developed it. He produced it. 1st Year of production - Ruin 2nd Year Same 3rd Year - Even money.
4th year - he got righ (i think he was already....)
I think protecting his right to produce the bulb was a good think. I think the guy deserved it.
Think about TetraPak - some company developed it. It costed them money. They are getting their revenues now.
The lost of monopoly over a technology may be important for the company or may not be. Go ask Intel to share their secrets about Chip manufacturing, clean rooms, oxidation times ,etc. They share what it is important to share. Somethings must remain a secret or protected because they were just to expensive to get.
But for the common good, things remain protected for a finite period of time. For developers to get their money back (at least).
After that is ours!
Dont u think that Edison deserved not only a place in history but a good life also. Newton, Eistein, Bohr, Dirac, etc....
How about the guy that invented the mouse? How about the guy that invented the Combo Box?
(u just added a new post!!!! :shock: )
Thats already hapening to cars in EU. But u should also see the problem the other way - maybe this new service providers ruin the sells because they are bad service/support providers and customer dont distinguish product from maintenance
Look to Autodesk re-selling - they take special care in re-sellers because they are the 1st contact with customer (even before the product) and they can ruin the products name ... (or sellings!!!)
But u do have a point there.
Hi Sherpen,
Very good point. Here in Romania, I was facing the same problems as you have, and I believe that your suggestion about making Navision simpler is 100% correct.
In my opinion, all this is coming from the fact that the guys that created the Business Logic at Navision did not never, ever went to try to implement their ERP at a customer's premises, and they did not ever ask the end-user about what he would really need. Instead, they took some books, read them (I do not say they understood them...
In the Inventory Cost Adjustment, I have corrected 3 major bugs, and I think I could say is working almost well [-o< . The same happened with the Requisition Worksheet, Reservation, and so on... Somehow I like to do it, because it shows me that I am able to do it, but it would be definitely easier for us to have a software that works and covers let's say 80-90% of customer's needs, and leave for us only the task to make improvements or to solve very specific requirements. And next, why should we do that? I assume they have bigger salaries than us, and definitely they do not loose 15 kg to make an implementation
I totally disagree with BlackTiger: I do not think that is possible to implement the standard Navision to a customer... unless he is not using the software
And finally, youre 100% right about the communism. I know from experience too. Sharing information openly is very good, because it is not like food or gold: if you share with someone else your knowledge, and ideas, you do not remain with less, but sometimes you can get even more.
Sorry to disagree again. Although I don't want to argue on politics, and I do not believe this is the scope of this forum, I can not restrain to comment.
How do you know what people want? How can you state that people in China is happy? Did you ask them? Made some polls? If you don't like the USA, why are you not going to China, where people is so happy
I know very well the idea that "before it was better". Probably the 99% that do not want freedom and were used to live on the other 1% account. I remember a slogan that was running here, and I believe it was used in USSR too: "Get from everyone according to his capability and give to everyone according to his needs".
To discuss why people was so happy in USSR give me a bitter taste, because our country lived in a big shadow for so long. Nothing personal against russians, I have very good friends from there, and I think they are extraordinary people as individuals, but the empire, like any other empire is not so lovely. I agree with you that is not as easy as it was before, but that is life. Anyhow, I preffer it as is now. Maybe for you it was better, for me it was definitely not.
OK, now regarding Navision. Yes, it is stupid to try to use the standard. It is as stupid as trying to buy a 500$ suite from the shop and expecting to wear it without going to the tailor to pay another 500$ to be re-fitted. And without the tailor to explain you that you should keep one shoulder lower and the other higher and your neck twisted, because this is the logic of this suite.
I do not think that everything is wrong in Navision, and I am not trying to re-invent the wheel. Simply I cannot accept that after 20 years this software is not doing what it should do, and what is promising to do. Did you ever implemented the ADCS? Does it work? Please look into this forum topics and see how many ](*,) you find.
And another fact of life that is for sure: all great things are simple. When something is too complicated, then you can be sure it won't work, or it will go faulty very soon. I mentioned that I have fixed several major bugs in the cost adjustment and requisition worksheet. You know what they have done? They made the code so unneccessary complicated that the Needed Quantity was added twice, for instance. 8-[
Have a nice weekend.
1. The application approach. Sometimes I think Mibuso is too developer oriented. Application consultants, salespeople and end users aren’t getting much attention. I’m not sure if I have a solution to that problem, but I think you could try to have separate forums for different persons, role oriented
If so I think you could start with a forum for application consultants, and maybe a forum for end users. It would also be great if these forums could have RSS-feeds of their own.
2. The balanced, end user oriented view of Navision. Not defending it to the bone and not blaming it for every problem on earth.
Keep up the good work Shenpen
This is most certainly not true. I started with 3.6 and it was hell. I have read most of the support requests on Service System for 3.1 and 2.6 and it was an even bigger hell. The problem is not that you have fix bugs but when implement a given version the first 3 times, you really can fall out of project schedule because you have to chase bugs.
And when Microsoft truly stepped in, in 3.7 a great number of old bugs were corrected. It continued in 3.7B and 4.0 - now I 4.0 the usual Inventory Costing deadlocks and such are completely gone.
Yes, Microsoft has some really stupid ideas, like the Sales Order Info Pane, but bugfixing is really great.
I think Microsoft has more info on how end users work than Navision A/S ever had. For example, in Manufacturing, this new Order Planning and "posting journal right on the Prod. Ord." features are very typical: simplyfied and practical functions instead of the theoretical and overcomplicated procedurs of Navison A/S.
My only big problem with MS is "packaging": buy Office 2003 to have Outlook Sync, buy IIS to have SmartTag, buy Exchange to have e-mail logging...
Do It Yourself is they key. Standard code might work - your code surely works.